From noreply at sourceforge.net Sun Aug 1 15:10:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 15:10:57 2004 Subject: [Patches] [ python-Patches-979728 ] Implementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 13:26 Message generated for change (Comment added) made by mark_t_russell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Mark Russell (mark_t_russell) Date: 2004-08-01 13:10 Message: Logged In: YES user_id=1017234 Ignore the "Issues:" paragraph in my previous comment - I made is_method() test_pyclbr.py a bit smarter and the test now passes. I also added a file Lib/test/pyclbr_input.py to use as a test module rather than test_decorators.py. ---------------------------------------------------------------------- Comment By: Mark Russell (mark_t_russell) Date: 2004-07-31 21:49 Message: Logged In: YES user_id=1017234 I've updated the patch again. See my previous comment here for the procedure to apply the patch. Main changes: - Added decorator support to Lib/compiler. test_decorators.py now passes when compiled with Lib/compiler. The regression tests also pass when built with Tools/compiler/regrtest.py, apart from test_dis.py which I assume is due to trivial differences in the bytecode output. - Added a description of decorators to the reference manual. Changed the docs for staticmethod and classmethod in the library manual to use decorator syntax (with a pointer to the decorator description in the reference manual). - Added more tests to test_decorator.py, including some possibly useful example decorators (e.g. memoize) Other changes (not directly related to decorators): - I regenerated Lib/compiler/ast.py using Tools/compiler/astgen.py. I'm not sure whether astgen.py is still in use -- I had to tweak it a bit to make the output match ast.py. I changed astgen.py to emit the classes in alphabetical rather than dict scan order to make it easier to diff the output against ast.py - test_pyclbr.py had a broken definition of assertEquals - it always returned True if called with two arguments. I renamed this to assertEqualsOrIgnored and fixed the bug. The working test revealed a test failure in pyclbr.py: - Changed pyclbr to use the full (dotted) module name for pyclbr.Class.module attribute Issues: - test_pyclbr.py currently fails because its is_method() method fails to spot staticmethod- and classmethod- wrapped methods. See the comment on the new test test_decorators(). I'll have another look at this next week. Note that this is a problem with the test, not the pyclbr.py module. For now test_decorator could just be deleted. ---------------------------------------------------------------------- Comment By: Mark Russell (mark_t_russell) Date: 2004-07-28 17:37 Message: Logged In: YES user_id=1017234 I've added an updated version of the patch, with the following changes: - Applied against CVS head (as of 2004-07-28) - Non-standard C removed (see Guido's comment) - Newline before the def is now mandatory - Grammer for decorator expressions more restricted - tokenize.py and test_tokenize updated to handle @ tokens - Lib/compiler/transformer.py minimally updated Still to do: - Complete work on Lib/compiler (i.e. get it to the point where it produces a correct .pyc for code with decorators). - Write docs - Work through all the steps in PEP 306 - Add more regression tests to test_decorator I can put in some time on this in the next few days if this patch seems likely to be applied. The grammar is now: decorator: '@' dotted_name [ '(' [arglist] ')' ] decorators: decorator ([NEWLINE] decorator)* NEWLINE funcdef: [decorators] 'def' NAME parameters ':' suite This allows @foo @bar def f(): pass but not: @foo @bar def f(): paqss Issues: - Someone should take a look at the "case decorator:" code in symtable_node() in compile.c. All the tests pass, but this seems a fragile bit of code to be changing - Lib/compiler needs some more work - at present decorators are ignored there. I'll do some more work on this when I get time (probably this weekend). - As noted in the comments here, the build system does not cope automatically with grammar changes. The steps I used to apply the patch are: cd .../dist/src patch -p0 < /path/to/patch-file ./configure make chmod +w Lib/symbol.py Lib/token.py ./python Lib/symbol.py ./python Lib/token.py make clean make make test >& make-test.out I'm sure this sequence is non-optimal, but it works for me, and all the tests pass on my Linux system afterwards. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-07-28 03:39 Message: Logged In: YES user_id=6380 There's some non-standard C: in compile.c line 5641 there's a char* declaration that isn't at the start of a block. Easily fixed but should definitely be fixed before releasing a2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-07-28 03:22 Message: Logged In: YES user_id=6380 Before 2.4final I'd like to see some changes to the syntax: - Instead of @test, it should be somewhat more restricted, preferably @ followed by a dotted name followed by an optional argument list. @1+2 or @[1,2,3] just doesn't make sense IMO. - I'd like there to always be a newline between the last decorator and the 'def' keyword. (This in the sake of "greppability" per python-dev discussion.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-26 14:20 Message: Logged In: YES user_id=6656 Well, PEP 306 is the reference for this sort of thing: also needed (before 2.4 final) are changes to Lib/compiler and tokenize.py. Mark, are you willing/able to work on these? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 14:09 Message: Logged In: YES user_id=29957 Argh. Our Makefile's ability to Do The Right Thing... is not good. Rebuilding Lib/symbol.py and Lib/token.py makes this better. The setup.py really should do this automatically. So - all tests pass. As far as I can see, things still to be done for this to be in a2: - Documentation (can wait until a3, I guess) - More coverage in test_decorator (ditto) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 13:58 Message: Logged In: YES user_id=29957 I still get a failure in test_transformer after a make distclean and rebuild and make distclean and rebuild. FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_transformer.py", line 37, in ? test_main() File "Lib/test/test_transformer.py", line 32, in test_main test_support.run_unittest( File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_transformer.py", line 16, in testMultipleLHS a = transformer.parse(s) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 50, in parse return Transformer().parsesuite(buf) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 120, in parsesuite return self.transform(parser.suite(text)) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 113, in transform return self.compile_node(tree) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 149, in compile_node return self.file_input(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 180, in file_input self.com_append_stmt(stmts, node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1025, in com_append_stmt result = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 252, in stmt return self.com_stmt(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1018, in com_stmt result = self.lookup_node(node)(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 312, in expr_stmt lval = self.com_augassign(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 922, in com_augassign l = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) KeyError: 268 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 13:41 Message: Logged In: YES user_id=29957 Hm. Pilot error on my part. I had to build once to get graminit.h and graminit.c rebuilt, then rebuild again (after nuking all .o files) to get it to work properly. *sigh* ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 13:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Sun Aug 1 17:29:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 17:29:42 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 08:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 10:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 06:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 04:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 15:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Aug 1 18:34:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 18:34:16 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 08:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 11:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 10:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 06:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 04:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 15:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Aug 1 20:42:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 20:42:18 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 08:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 13:42 Message: Logged In: YES user_id=80475 Further timings show it is advantageous to keep BINARY_ADD and INPLACE_ADD separate. Revised patch attached. Now all benchmark tests show improvements. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 11:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 10:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 06:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 04:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 15:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Sun Aug 1 21:33:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 21:33:11 2004 Subject: [Patches] [ python-Patches-1001610 ] socketmodule on OpenBSD/sparc64 (64bit machine) Message-ID: Patches item #1001610, was opened at 2004-08-01 21: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=1001610&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aleksander Piotrowski (pelotas) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule on OpenBSD/sparc64 (64bit machine) Initial Comment: In revision 1.280 of Modules/socketmodule.c, perky has fixed some problems of socketmodule on 64bit arches. On my OpenBSD/sparc64 (SUN Ultra 10) this change is not enough. Attached patch (which is currently part of python port for OpenBSD) is necessary. In private mail, perky said that this change might be OK for OpenBSD but doesn't work for other OSes. Attached diff is against 2.3.4. BTW this another unsigned long to int change doesn't break OpenBSD/i386. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001610&group_id=5470 From noreply at sourceforge.net Mon Aug 2 00:31:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 00:32:00 2004 Subject: [Patches] [ python-Patches-1001604 ] glob doesn't return unicode with no dir in unicode filename Message-ID: Patches item #1001604, was opened at 2004-08-01 15:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) >Summary: glob doesn't return unicode with no dir in unicode filename Initial Comment: #Here is the script #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # #The second line should be too. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-01 18:31 Message: Logged In: YES user_id=33168 The attached patch fixes the problem and all tests pass on Linux. But I'm not really sure if this should be fixed or not. Perhaps someone more familiar with unicode and filenames (like Martin or Marc-Andre?) could provide feedback. I don't know if this could create any problems on Windows. Changing to a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 From noreply at sourceforge.net Mon Aug 2 01:11:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 01:12:02 2004 Subject: [Patches] [ python-Patches-1001610 ] socketmodule on OpenBSD/sparc64 (64bit machine) Message-ID: Patches item #1001610, was opened at 2004-08-01 21:33 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001610&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aleksander Piotrowski (pelotas) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule on OpenBSD/sparc64 (64bit machine) Initial Comment: In revision 1.280 of Modules/socketmodule.c, perky has fixed some problems of socketmodule on 64bit arches. On my OpenBSD/sparc64 (SUN Ultra 10) this change is not enough. Attached patch (which is currently part of python port for OpenBSD) is necessary. In private mail, perky said that this change might be OK for OpenBSD but doesn't work for other OSes. Attached diff is against 2.3.4. BTW this another unsigned long to int change doesn't break OpenBSD/i386. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 01:11 Message: Logged In: YES user_id=21627 This patch is incorrect. On your system, I believe, inet_addr does not return int, but in_addr_t. Therefore, you should write an autoconf test that tests whether in_addr_t is available on the system. If the type is not available, check whether unsigned long int has size 4. If it doesn't, check whether unsigned int has size 4. Of these three types, use the first one that matches; generate an #error if you can't find a suitable type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001610&group_id=5470 From noreply at sourceforge.net Mon Aug 2 02:09:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 02:09:08 2004 Subject: [Patches] [ python-Patches-1001604 ] glob doesn't return unicode with no dir in unicode filename Message-ID: Patches item #1001604, was opened at 2004-08-02 05:20 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with no dir in unicode filename Initial Comment: #Here is the script #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # #The second line should be too. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2004-08-02 10:09 Message: Logged In: YES user_id=12579 I wrote a slightly different patch that converts the os.curdir to Unicode inside glob but the patch here is just as good. The nnorwitz patch works well for me on Windows with Unicode file names: >>> glob.glob("*") ['a.bat', 'abc', 'ascii', 'b.bat', 'fileobject.c', 'fileobject.c.diff', 'Gr\xfc\xdf-Gott', 'pep-0277.txt', 'posixmodule.c', 'posixmodule.c.diff', 'uni.py', 'winunichanges.zip', 'Ge??-sa?', '????????????', '??????', '???', '????G\xdf', '???'] >>> glob.glob(u"*") [u'a.bat', u'abc', u'ascii', u'b.bat', u'fileobject.c', u'fileobject.c.diff', u'Gr\xfc\xdf-Gott', u'pep-0277.txt', u'posixmodule.c', u'posixmodule.c.diff', u'uni.py', u'winunichanges.zip', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] Here is my patch if you are interested: --- glob.py Wed Jun 06 06:24:38 2001 +++ g:\Python23\Lib\glob.py Sun Aug 01 23:50:43 2004 @@ -19,7 +19,10 @@ return [] dirname, basename = os.path.split(pathname) if not dirname: - return glob1(os.curdir, basename) + # Use the current directory but match the argument + # string form, either unicode or string. + dirname = type(dirname)(os.curdir) + return glob1(dirname, basename) elif has_magic(dirname): list = glob(dirname) else: @@ -40,7 +43,7 @@ return result def glob1(dirname, pattern): - if not dirname: dirname = os.curdir + assert dirname try: names = os.listdir(dirname) except os.error: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-02 08:31 Message: Logged In: YES user_id=33168 The attached patch fixes the problem and all tests pass on Linux. But I'm not really sure if this should be fixed or not. Perhaps someone more familiar with unicode and filenames (like Martin or Marc-Andre?) could provide feedback. I don't know if this could create any problems on Windows. Changing to a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 From Shelly at slamdunkfan.com Mon Aug 2 07:10:07 2004 From: Shelly at slamdunkfan.com (Shelly@slamdunkfan.com) Date: Mon Aug 2 06:09:52 2004 Subject: [Patches] Old lady gets ass fucked really hard!...portent Message-ID: <156424e6q84tq$63we08b1n43$06n5ou@total.kyokofukada.net> >Take a hair of the dog that bit you >The One who tells the stories rules the world Sucking a virgin clit through the panties is not an easy task to do for an old hot lady. But she will luckily manage it. Girls they are beautiful, no matter what their age is. Because woman s beauty doesn t shade down, it reborns when they get older. And short hairdo makes them look so adorable and so horny that s not possible not to cum! Watch them, try them. They will thank you. Some exclusive-samples here: http://tassel.mature-vision.info/4/ Uncubscribers-page here: http://reave.matures-in-act.info/mv.php?score >There is a time to speak and a time to be silent >Draw Not Your Bow Till the Arrow is Fixed >One good turn deserves another. From noreply at sourceforge.net Mon Aug 2 06:37:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 06:37:49 2004 Subject: [Patches] [ python-Patches-996316 ] New patch for Python 2.3 spec file. Message-ID: Patches item #996316, was opened at 2004-07-23 04:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: Sean Reifschneider (jafo) Summary: New patch for Python 2.3 spec file. Initial Comment: The changes in here probably can be used for the preliminary 2.4 spec file as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 06:37 Message: Logged In: YES user_id=21627 Assigning to jafo. jafo, feel free to make the changes that you consider necessary; for this one, please close the tracker item when done. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-07-26 23:47 Message: Logged In: YES user_id=81797 Yes, copying it to 2.4 and s/2.3/2.4/ should be a good start. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 16:35 Message: Logged In: YES user_id=29957 Applied as Checking in python-2.3.spec; /cvsroot/python/python/dist/src/Misc/RPM/Attic/python-2.3.spec,v <-- python-2.3.spec new revision: 1.2.12.14; previous revision: 1.2.12.13 done Should I just copy this (patched) file to python-2.4.spec, and s/2.3/2.4/ (that's pretty much what the current file is). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-07-23 05:11 Message: Logged In: YES user_id=81797 Grrr. sf.net seems to be having problems with file uploads. It's complaining that the file is <20 bytes or >256KB. Pick up the file from: ftp://ftp.python.org/python/2.3.4/rpms/python-spec-2.3.4-3.patch Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996316&group_id=5470 From noreply at sourceforge.net Mon Aug 2 08:16:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 08:16:23 2004 Subject: [Patches] [ python-Patches-979728 ] Implementation for PEP 318 using java-style syntax Message-ID: Patches item #979728, was opened at 2004-06-25 23:26 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mark Russell (mark_t_russell) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Implementation for PEP 318 using java-style syntax Initial Comment: This implements function decorators using the Java-style syntax described in http://mail.python.org/pipermail/python-dev/2004-June/045516.html As the patch changes the grammar, you'll need to make sure Include/graminit.h and Python/graminit.c are writable after applying the patch but before compiling (after a standard CVS checkout they are read-only, which stops pgen from working). Changes: - adding @ as a token - changing the grammer for funcdef - adding com_decorator in compile.c - adding test_decorator.py (based on Guido's version) ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-02 16:16 Message: Logged In: YES user_id=29957 Checked in on the trunk. I think I got everything. Thanks for your work on this! /cvsroot/python/python/dist/src/Doc/lib/asttable.tex,v <-- asttable.tex new revision: 1.2; previous revision: 1.1 /cvsroot/python/python/dist/src/Doc/lib/libfuncs.tex,v <-- libfuncs.tex new revision: 1.168; previous revision: 1.167 /cvsroot/python/python/dist/src/Doc/ref/ref7.tex,v <-- ref7.tex new revision: 1.39; previous revision: 1.38 /cvsroot/python/python/dist/src/Grammar/Grammar,v <-- Grammar new revision: 1.50; previous revision: 1.49 /cvsroot/python/python/dist/src/Include/graminit.h,v <-- graminit.h new revision: 2.22; previous revision: 2.21 /cvsroot/python/python/dist/src/Include/node.h,v <-- node.h new revision: 2.23; previous revision: 2.22 /cvsroot/python/python/dist/src/Include/token.h,v <-- token.h new revision: 2.21; previous revision: 2.20 /cvsroot/python/python/dist/src/Lib/pyclbr.py,v <-- pyclbr.py new revision: 1.33; previous revision: 1.32 /cvsroot/python/python/dist/src/Lib/symbol.py,v <-- symbol.py new revision: 1.17; previous revision: 1.16 /cvsroot/python/python/dist/src/Lib/token.py,v <-- token.py new revision: 1.14; previous revision: 1.13 /cvsroot/python/python/dist/src/Lib/tokenize.py,v <-- tokenize.py new revision: 1.36; previous revision: 1.35 /cvsroot/python/python/dist/src/Lib/compiler/ast.py,v <-- ast.py new revision: 1.24; previous revision: 1.23 /cvsroot/python/python/dist/src/Lib/compiler/pycodegen.py,v <-- pycodegen.py /cvsroot/python/python/dist/src/Lib/compiler/symbols.py,v <-- symbols.py new revision: 1.16; previous revision: 1.15 /cvsroot/python/python/dist/src/Lib/compiler/transformer.py,v <-- transformer.py new revision: 1.41; previous revision: 1.40 /cvsroot/python/python/dist/src/Lib/test/pyclbr_input.py,v <-- pyclbr_input.py initial revision: 1.1 /cvsroot/python/python/dist/src/Lib/test/test_decorators.py,v <-- test_decorators.py initial revision: 1.1 /cvsroot/python/python/dist/src/Lib/test/test_parser.py,v <-- test_parser.py new revision: 1.19; previous revision: 1.18 /cvsroot/python/python/dist/src/Lib/test/test_pyclbr.py,v <-- test_pyclbr.py new revision: 1.22; previous revision: 1.21 /cvsroot/python/python/dist/src/Lib/test/tokenize_tests.txt,v <-- tokenize_tests.txt new revision: 1.2; previous revision: 1.1 /cvsroot/python/python/dist/src/Lib/test/output/test_tokenize,v <-- test_tokenize new revision: 1.9; previous revision: 1.8 /cvsroot/python/python/dist/src/Modules/parsermodule.c,v <-- parsermodule.c new revision: 2.83; previous revision: 2.82 /cvsroot/python/python/dist/src/Parser/tokenizer.c,v <-- tokenizer.c new revision: 2.75; previous revision: 2.74 /cvsroot/python/python/dist/src/Python/compile.c,v <-- compile.c new revision: 2.310; previous revision: 2.309 /cvsroot/python/python/dist/src/Python/graminit.c,v <-- graminit.c new revision: 2.36; previous revision: 2.35 /cvsroot/python/python/dist/src/Tools/compiler/ast.txt,v <-- ast.txt new revision: 1.6; previous revision: 1.5 /cvsroot/python/python/dist/src/Tools/compiler/astgen.py,v <-- astgen.py new revision: 1.8; previous revision: 1.7 /cvsroot/python/python/dist/src/Tools/compiler/regrtest.py,v <-- regrtest.py new revision: 1.5; previous revision: 1.4 ---------------------------------------------------------------------- Comment By: Mark Russell (mark_t_russell) Date: 2004-08-01 23:10 Message: Logged In: YES user_id=1017234 Ignore the "Issues:" paragraph in my previous comment - I made is_method() test_pyclbr.py a bit smarter and the test now passes. I also added a file Lib/test/pyclbr_input.py to use as a test module rather than test_decorators.py. ---------------------------------------------------------------------- Comment By: Mark Russell (mark_t_russell) Date: 2004-08-01 07:49 Message: Logged In: YES user_id=1017234 I've updated the patch again. See my previous comment here for the procedure to apply the patch. Main changes: - Added decorator support to Lib/compiler. test_decorators.py now passes when compiled with Lib/compiler. The regression tests also pass when built with Tools/compiler/regrtest.py, apart from test_dis.py which I assume is due to trivial differences in the bytecode output. - Added a description of decorators to the reference manual. Changed the docs for staticmethod and classmethod in the library manual to use decorator syntax (with a pointer to the decorator description in the reference manual). - Added more tests to test_decorator.py, including some possibly useful example decorators (e.g. memoize) Other changes (not directly related to decorators): - I regenerated Lib/compiler/ast.py using Tools/compiler/astgen.py. I'm not sure whether astgen.py is still in use -- I had to tweak it a bit to make the output match ast.py. I changed astgen.py to emit the classes in alphabetical rather than dict scan order to make it easier to diff the output against ast.py - test_pyclbr.py had a broken definition of assertEquals - it always returned True if called with two arguments. I renamed this to assertEqualsOrIgnored and fixed the bug. The working test revealed a test failure in pyclbr.py: - Changed pyclbr to use the full (dotted) module name for pyclbr.Class.module attribute Issues: - test_pyclbr.py currently fails because its is_method() method fails to spot staticmethod- and classmethod- wrapped methods. See the comment on the new test test_decorators(). I'll have another look at this next week. Note that this is a problem with the test, not the pyclbr.py module. For now test_decorator could just be deleted. ---------------------------------------------------------------------- Comment By: Mark Russell (mark_t_russell) Date: 2004-07-29 03:37 Message: Logged In: YES user_id=1017234 I've added an updated version of the patch, with the following changes: - Applied against CVS head (as of 2004-07-28) - Non-standard C removed (see Guido's comment) - Newline before the def is now mandatory - Grammer for decorator expressions more restricted - tokenize.py and test_tokenize updated to handle @ tokens - Lib/compiler/transformer.py minimally updated Still to do: - Complete work on Lib/compiler (i.e. get it to the point where it produces a correct .pyc for code with decorators). - Write docs - Work through all the steps in PEP 306 - Add more regression tests to test_decorator I can put in some time on this in the next few days if this patch seems likely to be applied. The grammar is now: decorator: '@' dotted_name [ '(' [arglist] ')' ] decorators: decorator ([NEWLINE] decorator)* NEWLINE funcdef: [decorators] 'def' NAME parameters ':' suite This allows @foo @bar def f(): pass but not: @foo @bar def f(): paqss Issues: - Someone should take a look at the "case decorator:" code in symtable_node() in compile.c. All the tests pass, but this seems a fragile bit of code to be changing - Lib/compiler needs some more work - at present decorators are ignored there. I'll do some more work on this when I get time (probably this weekend). - As noted in the comments here, the build system does not cope automatically with grammar changes. The steps I used to apply the patch are: cd .../dist/src patch -p0 < /path/to/patch-file ./configure make chmod +w Lib/symbol.py Lib/token.py ./python Lib/symbol.py ./python Lib/token.py make clean make make test >& make-test.out I'm sure this sequence is non-optimal, but it works for me, and all the tests pass on my Linux system afterwards. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-07-28 13:39 Message: Logged In: YES user_id=6380 There's some non-standard C: in compile.c line 5641 there's a char* declaration that isn't at the start of a block. Easily fixed but should definitely be fixed before releasing a2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-07-28 13:22 Message: Logged In: YES user_id=6380 Before 2.4final I'd like to see some changes to the syntax: - Instead of @test, it should be somewhat more restricted, preferably @ followed by a dotted name followed by an optional argument list. @1+2 or @[1,2,3] just doesn't make sense IMO. - I'd like there to always be a newline between the last decorator and the 'def' keyword. (This in the sake of "greppability" per python-dev discussion.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-27 00:20 Message: Logged In: YES user_id=6656 Well, PEP 306 is the reference for this sort of thing: also needed (before 2.4 final) are changes to Lib/compiler and tokenize.py. Mark, are you willing/able to work on these? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-27 00:09 Message: Logged In: YES user_id=29957 Argh. Our Makefile's ability to Do The Right Thing... is not good. Rebuilding Lib/symbol.py and Lib/token.py makes this better. The setup.py really should do this automatically. So - all tests pass. As far as I can see, things still to be done for this to be in a2: - Documentation (can wait until a3, I guess) - More coverage in test_decorator (ditto) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:58 Message: Logged In: YES user_id=29957 I still get a failure in test_transformer after a make distclean and rebuild and make distclean and rebuild. FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_transformer.py", line 37, in ? test_main() File "Lib/test/test_transformer.py", line 32, in test_main test_support.run_unittest( File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_transformer.py", line 16, in testMultipleLHS a = transformer.parse(s) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 50, in parse return Transformer().parsesuite(buf) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 120, in parsesuite return self.transform(parser.suite(text)) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 113, in transform return self.compile_node(tree) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 149, in compile_node return self.file_input(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 180, in file_input self.com_append_stmt(stmts, node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1025, in com_append_stmt result = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 252, in stmt return self.com_stmt(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 1018, in com_stmt result = self.lookup_node(node)(node[1:]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 312, in expr_stmt lval = self.com_augassign(nodelist[0]) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 922, in com_augassign l = self.com_node(node) File "/home/anthony/src/py/pyhead/dist/src/Lib/compiler/transformer.py", line 768, in com_node return self._dispatch[node[0]](node[1:]) KeyError: 268 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:41 Message: Logged In: YES user_id=29957 Hm. Pilot error on my part. I had to build once to get graminit.h and graminit.c rebuilt, then rebuild again (after nuking all .o files) to get it to work properly. *sigh* ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-07-26 23:30 Message: Logged In: YES user_id=29957 After applying this patch, any attempts to use the newly-built python (I deleted graminit.c and graminit.h, to make sure they were rebuilt) gives the following on any 'import': *-s*) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt, imp, re SystemError: compile_node: unexpected node type make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=979728&group_id=5470 From noreply at sourceforge.net Mon Aug 2 08:53:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 08:53:41 2004 Subject: [Patches] [ python-Patches-941229 ] Allow any encodings other than latin-1 in interactive interp Message-ID: Patches item #941229, was opened at 2004-04-24 18:49 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Martin v. L?wis (loewis) Summary: Allow any encodings other than latin-1 in interactive interp Initial Comment: Python interactive interpreter uses ISO-8859-1 for parsing incoming codes from sys.stdin whatever sys.stdin.encoding is. This patch allows to use locale-aware encodings other than ISO-8859-1 in interactive sessions. eg. Before: >>> u'한글' # (U+D55C, U+AE00) u'\xc7\xd1\xb1\xdb' After: >>> u'한글' u'\ud55c\uae00' The attached sample implementation fall backs to ISO-8859-1 for any non-memory errors such as UnicodeDecodeError. So if you use ascii or iso-8859-1, you'll not able to find difference. It intended to affect to non-latin-1 encoding users. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-02 15:53 Message: Logged In: YES user_id=55188 I'd like to see some progression on this in upcoming 2.4a2. Can you please give some comment on this? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 From noreply at sourceforge.net Mon Aug 2 10:20:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 10:20:28 2004 Subject: [Patches] [ python-Patches-941229 ] Allow any encodings other than latin-1 in interactive interp Message-ID: Patches item #941229, was opened at 2004-04-24 11:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: Allow any encodings other than latin-1 in interactive interp Initial Comment: Python interactive interpreter uses ISO-8859-1 for parsing incoming codes from sys.stdin whatever sys.stdin.encoding is. This patch allows to use locale-aware encodings other than ISO-8859-1 in interactive sessions. eg. Before: >>> u'한글' # (U+D55C, U+AE00) u'\xc7\xd1\xb1\xdb' After: >>> u'한글' u'\ud55c\uae00' The attached sample implementation fall backs to ISO-8859-1 for any non-memory errors such as UnicodeDecodeError. So if you use ascii or iso-8859-1, you'll not able to find difference. It intended to affect to non-latin-1 encoding users. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 10:20 Message: Logged In: YES user_id=21627 The patch is fine, please apply. You might consider removing the error check for PyString_AsString - that function cannot fail. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-02 08:53 Message: Logged In: YES user_id=55188 I'd like to see some progression on this in upcoming 2.4a2. Can you please give some comment on this? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470 From noreply at sourceforge.net Mon Aug 2 10:35:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 10:35:38 2004 Subject: [Patches] [ python-Patches-1001864 ] Logger file objects Message-ID: Patches item #1001864, was opened at 2004-08-02 11: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=1001864&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Logger file objects Initial Comment: The logger can return a file like object for each error level. These file objects can be sent to any function expecting a file object. Example: >> import logging >> logging.basicConfig() >> logger = logging.getLogger() >> err = logger.getFileObject(logging.ERROR) >> print >> err, "This is an error" ERROR:root:This is an error ERROR:root: >> err.flush() >> err.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470 From noreply at sourceforge.net Mon Aug 2 13:10:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 13:10:57 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-02 11:10 Message: Logged In: YES user_id=4771 Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain. The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will. The rationale for only tampering with INPLACE_ADD was to make the result more predictable. Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b. In-place operators in Python are a dark corner of the language. I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators. Thus the idea of only tampering with INPLACE_ADD for the optimization here. Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 18:42 Message: Logged In: YES user_id=80475 Further timings show it is advantageous to keep BINARY_ADD and INPLACE_ADD separate. Revised patch attached. Now all benchmark tests show improvements. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 16:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 15:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 11:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 09:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 20:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From love at anan.servehalflife.com Mon Aug 2 16:09:47 2004 From: love at anan.servehalflife.com (love@anan.servehalflife.com) Date: Mon Aug 2 16:09:48 2004 Subject: [Patches] =?utf-8?b?wpBswo3DiMKDQcKDaMKDwozCg1jCksKg?= Message-ID: mag20040802213455 *:??,??'?:*:??,? ?????? ?17??*:??,??'?:*:??,? ???????????(???)? ?????????? =========================================================== =====================???==???======================== ================????==???????=================== =========================================================== ???????????????????????? ??????????????????? ??????????????????????????????? ??????????????????????????????? ????????????????????????????????? ???1????????????10?20????????????????????????? ??????????????????????????????? ??????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????????? ???????????????????????????????????? ???? ????????????????????????????????????? ??????????????????????????????????? ?????????????????????????????????? ??-------------------------------------------------???PR???-------?? ?????????????????????????????????????? ???????OK???????????????????????????????????? ????? ???????http://gannba.servepics.com/?g02 ??-------???PR???-------------------------------------------------?? ???????????????????????????? ???????????????????????? ???????http://zxcvb.servepics.com/?g02 ??------------------------------????---------------------------------???? ?????????????????????????????????????? ????????????????????????? ?????????????????????? From noreply at sourceforge.net Mon Aug 2 17:09:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 17:09:36 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 08:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 10:09 Message: Logged In: YES user_id=80475 I recommend doing both. When and where the optimization applies is an implementation detail (that probably won't be replicated in Jython for example). To do only inplace add is to miss much of the existing code that is in need of help. Several library modules and benchmarks benefit greatly from doing both. This makes common coding styles not result in disasterous performance. The explanation can read something like: "With binary additions of the form a+=b or a=a+b, CPython is able to concatenate inplace and achieve linear running time. However, with chained additions like a = a + b + c, the current implementation does not recognize the opportunity to concatenate inplace. Instead, a new string is constructed at each step resulting in quadratic running time." ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-02 06:10 Message: Logged In: YES user_id=4771 Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain. The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will. The rationale for only tampering with INPLACE_ADD was to make the result more predictable. Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b. In-place operators in Python are a dark corner of the language. I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators. Thus the idea of only tampering with INPLACE_ADD for the optimization here. Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 13:42 Message: Logged In: YES user_id=80475 Further timings show it is advantageous to keep BINARY_ADD and INPLACE_ADD separate. Revised patch attached. Now all benchmark tests show improvements. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 11:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 10:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 05:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 06:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 04:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 15:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Mon Aug 2 18:43:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 18:43:50 2004 Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing Message-ID: Patches item #1002085, was opened at 2004-08-02 09:43 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=1002085&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: O(1) xrange membership testing Initial Comment: this patch applies to anonymous CVS as of 2004-08-02 at 07: 54:58 PDT. it adds O(1) membership testing; for example: Python 2.4a1+ (#2, Aug 2 2004, 09:11:43) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 2147483647 >>> sys.maxint in xrange(sys.maxint) False in current CVS, this would take untold hours to complete (because Python arrives at this answer by iterating on the sequence). this patch adds a __contains__ method to the xrange object which examines the xrange's pattern and determines the correct answer instantly based on that pattern. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 From noreply at sourceforge.net Mon Aug 2 19:26:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 19:26:58 2004 Subject: [Patches] [ python-Patches-1001109 ] posixpath._resolve_link typo Message-ID: Patches item #1001109, was opened at 2004-07-31 10:24 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001109&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: posixpath._resolve_link typo Initial Comment: _resolvelink calls abspath to test if a path is absolute, that should obviously be a call to isabs. Without this patch os.path.realpath returns the wrong result when the link contents is a relative path. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-02 19:26 Message: Logged In: YES user_id=580910 I'm closing this patch because someone else already checked in a fix. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-07-31 10:25 Message: Logged In: YES user_id=580910 Stupid SF interface, I forgot to check the upload box :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001109&group_id=5470 From noreply at sourceforge.net Mon Aug 2 19:28:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 19:28:45 2004 Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing Message-ID: Patches item #1002085, was opened at 2004-08-02 18:43 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: O(1) xrange membership testing Initial Comment: this patch applies to anonymous CVS as of 2004-08-02 at 07: 54:58 PDT. it adds O(1) membership testing; for example: Python 2.4a1+ (#2, Aug 2 2004, 09:11:43) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 2147483647 >>> sys.maxint in xrange(sys.maxint) False in current CVS, this would take untold hours to complete (because Python arrives at this answer by iterating on the sequence). this patch adds a __contains__ method to the xrange object which examines the xrange's pattern and determines the correct answer instantly based on that pattern. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-02 19:28 Message: Logged In: YES user_id=580910 You forgot to add the patch (did you check the checkbox?). BTW. Does your patch include unittests? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 From noreply at sourceforge.net Mon Aug 2 20:25:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 20:25:54 2004 Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing Message-ID: Patches item #1002085, was opened at 2004-08-02 09:43 Message generated for change (Comment added) made by boredzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: O(1) xrange membership testing Initial Comment: this patch applies to anonymous CVS as of 2004-08-02 at 07: 54:58 PDT. it adds O(1) membership testing; for example: Python 2.4a1+ (#2, Aug 2 2004, 09:11:43) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 2147483647 >>> sys.maxint in xrange(sys.maxint) False in current CVS, this would take untold hours to complete (because Python arrives at this answer by iterating on the sequence). this patch adds a __contains__ method to the xrange object which examines the xrange's pattern and determines the correct answer instantly based on that pattern. ---------------------------------------------------------------------- >Comment By: Mac-arena the Bored Zo (boredzo) Date: 2004-08-02 11:25 Message: Logged In: YES user_id=711099 heh, no I didn't check the checkbox. thanks for reminding me. :) the original patch didn't include unit tests, but that is a good idea. ;) so I've added changes to test_xrange.py. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-02 10:28 Message: Logged In: YES user_id=580910 You forgot to add the patch (did you check the checkbox?). BTW. Does your patch include unittests? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 From noreply at sourceforge.net Mon Aug 2 21:42:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 21:42:18 2004 Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing Message-ID: Patches item #1002085, was opened at 2004-08-02 09:43 Message generated for change (Comment added) made by boredzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: O(1) xrange membership testing Initial Comment: this patch applies to anonymous CVS as of 2004-08-02 at 07: 54:58 PDT. it adds O(1) membership testing; for example: Python 2.4a1+ (#2, Aug 2 2004, 09:11:43) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 2147483647 >>> sys.maxint in xrange(sys.maxint) False in current CVS, this would take untold hours to complete (because Python arrives at this answer by iterating on the sequence). this patch adds a __contains__ method to the xrange object which examines the xrange's pattern and determines the correct answer instantly based on that pattern. ---------------------------------------------------------------------- >Comment By: Mac-arena the Bored Zo (boredzo) Date: 2004-08-02 12:42 Message: Logged In: YES user_id=711099 found and fixed a bug: the new __contains__ method didn't check for an exception from PyInt_AsLong. ---------------------------------------------------------------------- Comment By: Mac-arena the Bored Zo (boredzo) Date: 2004-08-02 11:25 Message: Logged In: YES user_id=711099 heh, no I didn't check the checkbox. thanks for reminding me. :) the original patch didn't include unit tests, but that is a good idea. ;) so I've added changes to test_xrange.py. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-02 10:28 Message: Logged In: YES user_id=580910 You forgot to add the patch (did you check the checkbox?). BTW. Does your patch include unittests? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 From noreply at sourceforge.net Mon Aug 2 22:37:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 22:37:53 2004 Subject: [Patches] [ python-Patches-1002241 ] Better extensibility for distutils commands Message-ID: Patches item #1002241, was opened at 2004-08-02 16: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=1002241&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Better extensibility for distutils commands Initial Comment: This allows additional commands to be provided for existing setup.py scripts without modifying either the distutils installation or the setup.py scripts of packages with which the new commands will be used. Specifically, an option is added to distutils that allows additional packages to be searched for command implementations in addition to distutils.command. The additional packages can be specified on the command line or via the installation or personal configuration files already loaded by distutils. For discussion, see the thread starting with: http://mail.python.org/pipermail/distutils-sig/2004-August/004112.html This patch adds the feature and unit tests; I'll add an additional patch with documentation updates when that's ready. I'd like this to appear in the 2.4a2 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002241&group_id=5470 From love at anan.servehalflife.com Tue Aug 3 07:04:24 2004 From: love at anan.servehalflife.com (love@anan.servehalflife.com) Date: Tue Aug 3 07:04:26 2004 Subject: [Patches] =?utf-8?b?wpBswo3DiMKDQcKDaMKDwozCg1jCksKg?= Message-ID: mag20040802223614 *:??,??'?:*:??,? ?????? ?17??*:??,??'?:*:??,? ???????????(???)? ?????????? =========================================================== =====================???==???======================== ================????==???????=================== =========================================================== ???????????????????????? ??????????????????? ??????????????????????????????? ??????????????????????????????? ????????????????????????????????? ???1????????????10?20????????????????????????? ??????????????????????????????? ??????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????????? ???????????????????????????????????? ???? ????????????????????????????????????? ??????????????????????????????????? ?????????????????????????????????? ??-------------------------------------------------???PR???-------?? ?????????????????????????????????????? ???????OK???????????????????????????????????? ????? ???????http://gannba.servepics.com/?g02 ??-------???PR???-------------------------------------------------?? ???????????????????????????? ???????????????????????? ???????http://zxcvb.servepics.com/?g02 ??------------------------------????---------------------------------???? ?????????????????????????????????????? ????????????????????????? ?????????????????????? From noreply at sourceforge.net Tue Aug 3 11:36:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 11:37:03 2004 Subject: [Patches] [ python-Patches-995939 ] Avoid calling tp_compare with different types Message-ID: Patches item #995939, was opened at 2004-07-22 14:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&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: Avoid calling tp_compare with different types Initial Comment: C implementations of the tp_compare slot usually expect both of their arguments to have the type for which that slot is defined (this isn't documented anywhere that I can find, but many core types assume this, and extension authors are likely to do the same). A problem occurs if a user-defined nb_coerce slot (__coerce__) returns objects with different types. Avoid the problem by refusing to call a non-Python tp_compare unless the arguments have the same type. Indiscriminately calling tp_compare with different types is wrong as long as there are implementations that don't check the type of the second argument, but Python implementations should be allowed to receive a different type. Other options for fixing the problem: - Make PyNumber_CoerceEx require that the results have the same type. This would prevent a user-defined __coerce__ from communicating an arbitrary object to a user-defined __cmp__. Furthermore, there are uses for coerce besides comparison, and those uses might not require identical types. - Change tp_compare implementations to check the type of the second argument. This might be the most desirable long-term solution, but as I understand it, tp_richcompare is preferred over tp_compare for new code, and old (current) code is likely assuming that the types are the same. Addresses bug #980352 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-03 09:36 Message: Logged In: YES user_id=4771 Is your patch complete? There seem to be a lot of places in object.c that call tp_compare slots. Shouldn't we try to make sure that none of these places can ever be called with two different types? It also looks like we have to do something special about a value of &_PyObject_SlotCompare in tp_compare, because this function from typeobject.c checks itself the type of its arguments and does specific things with them. This should be thought about. Moreover there is the issue of the user subclassing built-in types, e.g. PyInt_Type.tp_compare is capable of comparing different user subclasses of "int" for each other. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470 From noreply at sourceforge.net Tue Aug 3 13:19:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 13:19:57 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 13:39 Message generated for change (Comment added) made by pedronis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Samuele Pedroni (pedronis) Date: 2004-08-03 11:19 Message: Logged In: YES user_id=61408 well, given the refcnt dependence and other issues, this cannot be reproduced in Jython (and similar impl. of Python). the issue is then that the std library itself cannot depend on the optimisation because the std library is shared among impls. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 15:09 Message: Logged In: YES user_id=80475 I recommend doing both. When and where the optimization applies is an implementation detail (that probably won't be replicated in Jython for example). To do only inplace add is to miss much of the existing code that is in need of help. Several library modules and benchmarks benefit greatly from doing both. This makes common coding styles not result in disasterous performance. The explanation can read something like: "With binary additions of the form a+=b or a=a+b, CPython is able to concatenate inplace and achieve linear running time. However, with chained additions like a = a + b + c, the current implementation does not recognize the opportunity to concatenate inplace. Instead, a new string is constructed at each step resulting in quadratic running time." ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-02 11:10 Message: Logged In: YES user_id=4771 Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain. The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will. The rationale for only tampering with INPLACE_ADD was to make the result more predictable. Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b. In-place operators in Python are a dark corner of the language. I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators. Thus the idea of only tampering with INPLACE_ADD for the optimization here. Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 18:42 Message: Logged In: YES user_id=80475 Further timings show it is advantageous to keep BINARY_ADD and INPLACE_ADD separate. Revised patch attached. Now all benchmark tests show improvements. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 16:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 15:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 10:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 11:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 09:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 20:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Tue Aug 3 14:37:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 14:37:58 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 09:39 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2004-08-03 08:37 Message: Logged In: YES user_id=99874 While I think CPython should get the patch, I *am* worried about Jython (and Iron Python I suppose). In particular, Samuele's plea to keep this out of the std library is likely to be followed for a few months, then completely forgotten. Perhaps we need some way to check, when running the test suite, just how much dependence there is on this feature... then there's at least be a way to *find* the bits where people who didn't predate this change failed to use the obscure ''.join() idiom that us oldtimers keep nagging about . ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2004-08-03 07:19 Message: Logged In: YES user_id=61408 well, given the refcnt dependence and other issues, this cannot be reproduced in Jython (and similar impl. of Python). the issue is then that the std library itself cannot depend on the optimisation because the std library is shared among impls. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:09 Message: Logged In: YES user_id=80475 I recommend doing both. When and where the optimization applies is an implementation detail (that probably won't be replicated in Jython for example). To do only inplace add is to miss much of the existing code that is in need of help. Several library modules and benchmarks benefit greatly from doing both. This makes common coding styles not result in disasterous performance. The explanation can read something like: "With binary additions of the form a+=b or a=a+b, CPython is able to concatenate inplace and achieve linear running time. However, with chained additions like a = a + b + c, the current implementation does not recognize the opportunity to concatenate inplace. Instead, a new string is constructed at each step resulting in quadratic running time." ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-02 07:10 Message: Logged In: YES user_id=4771 Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain. The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will. The rationale for only tampering with INPLACE_ADD was to make the result more predictable. Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b. In-place operators in Python are a dark corner of the language. I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators. Thus the idea of only tampering with INPLACE_ADD for the optimization here. Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 14:42 Message: Logged In: YES user_id=80475 Further timings show it is advantageous to keep BINARY_ADD and INPLACE_ADD separate. Revised patch attached. Now all benchmark tests show improvements. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 12:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 11:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 06:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 06:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 07:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 05:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 16:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Tue Aug 3 14:50:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 14:50:28 2004 Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing Message-ID: Patches item #1002085, was opened at 2004-08-02 18:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: O(1) xrange membership testing Initial Comment: this patch applies to anonymous CVS as of 2004-08-02 at 07: 54:58 PDT. it adds O(1) membership testing; for example: Python 2.4a1+ (#2, Aug 2 2004, 09:11:43) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.maxint 2147483647 >>> sys.maxint in xrange(sys.maxint) False in current CVS, this would take untold hours to complete (because Python arrives at this answer by iterating on the sequence). this patch adds a __contains__ method to the xrange object which examines the xrange's pattern and determines the correct answer instantly based on that pattern. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 14:50 Message: Logged In: YES user_id=21627 This patch is incorrect. Currently, "s" in xrange(3,4) gives False. With the patch, it raises an exception. Your patch should only take integer objects into account. Any other object might have an __eq__ that makes it compare equal to a number from the range. ---------------------------------------------------------------------- Comment By: Mac-arena the Bored Zo (boredzo) Date: 2004-08-02 21:42 Message: Logged In: YES user_id=711099 found and fixed a bug: the new __contains__ method didn't check for an exception from PyInt_AsLong. ---------------------------------------------------------------------- Comment By: Mac-arena the Bored Zo (boredzo) Date: 2004-08-02 20:25 Message: Logged In: YES user_id=711099 heh, no I didn't check the checkbox. thanks for reminding me. :) the original patch didn't include unit tests, but that is a good idea. ;) so I've added changes to test_xrange.py. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-02 19:28 Message: Logged In: YES user_id=580910 You forgot to add the patch (did you check the checkbox?). BTW. Does your patch include unittests? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470 From noreply at sourceforge.net Tue Aug 3 15:01:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 15:03:11 2004 Subject: [Patches] [ python-Patches-994595 ] HTTP basic authentication problem Message-ID: Patches item #994595, was opened at 2004-07-20 17:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Catalin Marinas (c_marinas) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP basic authentication problem Initial Comment: The regular expression matching in the AbstractBasicAuthHandler.http_error_auth_reqed() function in the urllib2 module doesn't work if the authorization string returned by the server contains one or more words in front of 'Basic realm="..."'. The patch changes the rx.match() to rx.search(). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:01 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as urllib2.py 1.73 NEWS 1.1063 urllib2.py 1.53.6.7 NEWS 1.831.4.135 ---------------------------------------------------------------------- Comment By: Catalin Marinas (c_marinas) Date: 2004-07-27 10:37 Message: Logged In: YES user_id=82327 I was trying to access a MS Exchange web mail account through their Outlook Web Access (WebDAV) interface but could not authenticate. The authorisation header returned by the the server is: 'Negotiate, NTLM, Basic realm="..."'. I don't know wheather the MS server complies with any standard, but the patch solved my problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-26 14:19 Message: Logged In: YES user_id=21627 Can you please give an example of a header that is not correctly detected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=994595&group_id=5470 From noreply at sourceforge.net Tue Aug 3 15:08:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 15:08:40 2004 Subject: [Patches] [ python-Patches-977074 ] speed up md5: allow Encode and Decode to inline Message-ID: Patches item #977074, was opened at 2004-06-22 00:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977074&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: speed up md5: allow Encode and Decode to inline Initial Comment: gcc will only inline functions if they are defined before where they are used. So this patch just moves Encode and Decode up to the top of the file. This can provide a couple percent improvement in speed. (try timeit.py -s 'import md5; m=md5.new(); d="a"*64' 'm.update(d);m.digest()' and timeit.py -s 'import md5; m=md5.new(); d="a"*0x100000' 'm.update(d)' ) Decode is only used once, so allowing it to inline actually reduces the code size, Encode is used twice but its a pretty small function so it doesn't change the size much either way.. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as md5c.c 2.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977074&group_id=5470 From noreply at sourceforge.net Tue Aug 3 15:10:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 15:10:53 2004 Subject: [Patches] [ python-Patches-972991 ] fix build of docs in info format Message-ID: Patches item #972991, was opened at 2004-06-15 07:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Matthias Klose (doko) Summary: fix build of docs in info format Initial Comment: one of those a workaround in py2texi.el (verbatim environments are processed before comments) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:10 Message: Logged In: YES user_id=21627 The patch is fine. Please apply. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2004-07-11 09:56 Message: Logged In: YES user_id=60903 > need more documentation ??? - the libfuncs.tex patch fixes wrong latex. - the dist.tex patch avoid uncommenting the verbose environment by py2texi. ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-07-01 23:40 Message: Logged In: YES user_id=943591 need more documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:13:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:13:22 2004 Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation Message-ID: Patches item #980695, was opened at 2004-06-27 09:39 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: efficient string concatenation Initial Comment: A wild idea that makes repeated string concatenations efficient without changing stringobject.c. If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1. But with some hacks ceval.c can know that. Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME. So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already). If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory). With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely. As a side effect, other constructions like a+b+c+d+e+f also work in-place now. The patch would do with a lot more comments. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-08-03 10:13 Message: Logged In: YES user_id=6380 Not so fast, see python-dev. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-08-03 08:37 Message: Logged In: YES user_id=99874 While I think CPython should get the patch, I *am* worried about Jython (and Iron Python I suppose). In particular, Samuele's plea to keep this out of the std library is likely to be followed for a few months, then completely forgotten. Perhaps we need some way to check, when running the test suite, just how much dependence there is on this feature... then there's at least be a way to *find* the bits where people who didn't predate this change failed to use the obscure ''.join() idiom that us oldtimers keep nagging about . ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2004-08-03 07:19 Message: Logged In: YES user_id=61408 well, given the refcnt dependence and other issues, this cannot be reproduced in Jython (and similar impl. of Python). the issue is then that the std library itself cannot depend on the optimisation because the std library is shared among impls. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:09 Message: Logged In: YES user_id=80475 I recommend doing both. When and where the optimization applies is an implementation detail (that probably won't be replicated in Jython for example). To do only inplace add is to miss much of the existing code that is in need of help. Several library modules and benchmarks benefit greatly from doing both. This makes common coding styles not result in disasterous performance. The explanation can read something like: "With binary additions of the form a+=b or a=a+b, CPython is able to concatenate inplace and achieve linear running time. However, with chained additions like a = a + b + c, the current implementation does not recognize the opportunity to concatenate inplace. Instead, a new string is constructed at each step resulting in quadratic running time." ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-02 07:10 Message: Logged In: YES user_id=4771 Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain. The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will. The rationale for only tampering with INPLACE_ADD was to make the result more predictable. Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b. In-place operators in Python are a dark corner of the language. I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators. Thus the idea of only tampering with INPLACE_ADD for the optimization here. Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 14:42 Message: Logged In: YES user_id=80475 Further timings show it is advantageous to keep BINARY_ADD and INPLACE_ADD separate. Revised patch attached. Now all benchmark tests show improvements. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 12:34 Message: Logged In: YES user_id=80475 FWIW, I think the patch ought to also apply to BINARY_ADD. There is tons of code that writes a=a+b rather than a+=b. It's important that there not be a substantial performance difference between the two; otherwise, we're introducing another bit of arcana. Attached is a revised patch that combines BINARY_ADD with INPLACE_ADD for a net savings of instructions in ceval.c. The timings improve on all my benchmarks (PyBench for example runs 4% faster). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-01 11:29 Message: Logged In: YES user_id=80475 I've run with this for a couple of days and have not been able to break it. My benchmarks run slightly faster except for PyBench which is 0.1% slower. Regression tests pass without exception. The code itself looks fine and the approach makes sense. It does introduce some extra complexity and code duplication, but the patch is still unified and comprehensible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 06:18 Message: Logged In: YES user_id=4771 Raymond, do you have time to review it? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-25 06:17 Message: Logged In: YES user_id=4771 Here is another patch. This one focuses on simplicity, both implementation-wise and from the user's point of view: 1) It only makes repeated variable += expr faster. It doesn't touch the '+'. 2) It doesn't mess with the internals of strings and dicts any more. It is just one well-documented function now. The goal of this new patch is to be reviewable and maintainable, to get it in the core to stop people from being bitten by the performance of += (I just saw yet another example yesterday). ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-06-28 07:38 Message: Logged In: YES user_id=99874 Hmmm... Interesting. I kinda like it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-28 05:41 Message: Logged In: YES user_id=4771 another patch with support for STORE_DEREF (thanks Phillip for pointing it out) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 16:39 Message: Logged In: YES user_id=4771 resubmitted as a context diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:37:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:37:53 2004 Subject: [Patches] [ python-Patches-823072 ] add option to NOT use ~/.netrc in nntplib.NNTP() Message-ID: Patches item #823072, was opened at 2003-10-14 00:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823072&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Martin v. L?wis (loewis) Summary: add option to NOT use ~/.netrc in nntplib.NNTP() Initial Comment: [forwarded from http://bugs.debian.org/215446] It should be possible to circumvent the use of ~/.netrc when calling the nntplib.NNTP() method by adding an addtional parameter. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 16:37 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libnntplib.tex 1.32 nntplib.py 1.39 NEWS 1.1064 ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-11-16 15:23 Message: Logged In: YES user_id=60903 add doc patch ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2003-10-14 02:29 Message: Logged In: YES user_id=162094 No documentation (http://www.python.org/doc/current/lib/module- nntplib.html) patch provided. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823072&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:57:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:57:55 2004 Subject: [Patches] [ python-Patches-946153 ] askstring => grab fail Message-ID: Patches item #946153, was opened at 2004-05-02 01:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946153&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: wes (wweston) Assigned to: Martin v. L?wis (loewis) Summary: askstring => grab fail Initial Comment: Calling askstring results in a "grab fail" exception about 2/3rds of the time on redhat 9/Python 2.3.3. By inserting one line in: /usr/local/Python/lib/python2.3/lib-tk/Tkinter.py //line 521 the problem seems to go away. def grab_set(self): """Set grab for this widget. A grab directs all events to this and descendant widgets in the application.""" self.wait_visibility()############added##################### self.tk.call('grab', 'set', self._w) wes ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 16:57 Message: Logged In: YES user_id=21627 The patch is wrong: the grab_set function should really just invoke Tcl "grab set"; this should not change. Adding a wait_visibility() immediately before grab_set() in tkSimpleDialog has a negative effect on my system: the dialog does not appear anymore, but is minimized. Therefore, I'm rejecting this patch. Please submit a bug report that demonstrates your problem instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=946153&group_id=5470 From noreply at sourceforge.net Tue Aug 3 17:20:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 17:20:36 2004 Subject: [Patches] [ python-Patches-1002241 ] Better extensibility for distutils commands Message-ID: Patches item #1002241, was opened at 2004-08-02 16:37 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002241&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Better extensibility for distutils commands Initial Comment: This allows additional commands to be provided for existing setup.py scripts without modifying either the distutils installation or the setup.py scripts of packages with which the new commands will be used. Specifically, an option is added to distutils that allows additional packages to be searched for command implementations in addition to distutils.command. The additional packages can be specified on the command line or via the installation or personal configuration files already loaded by distutils. For discussion, see the thread starting with: http://mail.python.org/pipermail/distutils-sig/2004-August/004112.html This patch adds the feature and unit tests; I'll add an additional patch with documentation updates when that's ready. I'd like this to appear in the 2.4a2 release. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-03 11:20 Message: Logged In: YES user_id=3066 I've replaced the implementation patch with one that has unit tests that are not sensitive to existing distutils config files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002241&group_id=5470 From noreply at sourceforge.net Tue Aug 3 18:38:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 18:38:28 2004 Subject: [Patches] [ python-Patches-1002241 ] Better extensibility for distutils commands Message-ID: Patches item #1002241, was opened at 2004-08-02 16:37 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002241&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Better extensibility for distutils commands Initial Comment: This allows additional commands to be provided for existing setup.py scripts without modifying either the distutils installation or the setup.py scripts of packages with which the new commands will be used. Specifically, an option is added to distutils that allows additional packages to be searched for command implementations in addition to distutils.command. The additional packages can be specified on the command line or via the installation or personal configuration files already loaded by distutils. For discussion, see the thread starting with: http://mail.python.org/pipermail/distutils-sig/2004-August/004112.html This patch adds the feature and unit tests; I'll add an additional patch with documentation updates when that's ready. I'd like this to appear in the 2.4a2 release. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-03 12:38 Message: Logged In: YES user_id=3066 Committed as: Doc/dist/dist.tex 1.81 Lib/distutils/dist.py 1.68 Lib/distutils/tests/test_dist.py 1.1 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-03 11:20 Message: Logged In: YES user_id=3066 I've replaced the implementation patch with one that has unit tests that are not sensitive to existing distutils config files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002241&group_id=5470 From noreply at sourceforge.net Tue Aug 3 20:01:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 20:01:46 2004 Subject: [Patches] [ python-Patches-663482 ] 658254: accept None for time.ctime() and friends Message-ID: Patches item #663482, was opened at 2003-01-06 22:42 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Blunck (blunck2) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 658254: accept None for time.ctime() and friends Initial Comment: ctime(), gmtime(), and localtime() now support None and treat it as tho you passed no arguments at all. i am new to patching for py and am not sure if there are unit tests i should update. please advise... ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-03 14:01 Message: Logged In: YES user_id=3066 I'm afraid I've let too much time to go by for this to apply cleanly (my fault; sorry!). I've applied portions of the documentation and news patches, and replaced the implementation and test patches in my commit. Doc/lib/libtime.tex 1.65 Lib/test/test_time.py 1.18 Misc/NEWS 1.1065 Modules/timemodule.c 2.144 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-02 03:04 Message: Logged In: YES user_id=80475 Fred, here is Blunk's patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-06 16:38 Message: Logged In: YES user_id=357491 What do people think of this functionality? I personally don't see a need for it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 17:33 Message: Logged In: YES user_id=33168 There don't appear to be any direct tests, but it would still be nice to call the functions and verify they work ok. You could compare that abs(ctime() - ctime(None)) < .5, for example. Look in Lib/test/test_time.py. Also, the docs need to be updated, see Doc/lib/libtime.tex. That should be updated, ie change \optional(secs) with \optional{secs\code{ = None}}. Also, an entry in Misc/NEWS should be added since this is an API change. There is no attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470 From noreply at sourceforge.net Tue Aug 3 20:48:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 20:49:00 2004 Subject: [Patches] [ python-Patches-986929 ] Add support for sync and use "wish" options Message-ID: Patches item #986929, was opened at 2004-07-08 01:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986929&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L?wis (loewis) Summary: Add support for sync and use "wish" options Initial Comment: Tkinter/_tkinter is unable to set the sync and use options in the default Toplevel widget created when Tkinter.Tk is called. Like the Tcl/Tk wish shell, these options need be given in the argv tcl variable. This patch adds "sync" and "use" keyword arguments to Tkinter.Tk. The sync option says to "Execute all X server commands synchronously, so that errors are reported immediately. This will result in much slower execution, but it is useful for debugging." The use option says to "Specifies that the main window for the application is to be embedded in the window whose identifier is id, instead of being created as an independent toplevel window. Id must be specified in the same way as the value for the -use option for toplevel widgets (i.e. it has a form like that returned by the winfo id command)." ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 20:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as _tkinter.c 1.166 Tkinter.py 1.181 NEWS 1.1066 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=986929&group_id=5470 From noreply at sourceforge.net Tue Aug 3 22:23:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 22:24:04 2004 Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation Message-ID: Patches item #941881, was opened at 2004-04-25 19:05 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: PEP309 Partial implementation Initial Comment: This patch implements functional module which is introduced by PEP309. It has only 'partial' function as its member in this stage. Unittest code is copied and modified slightly from Patch #931010 by Peter Harris. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-08-03 21:23 Message: Logged In: YES user_id=113328 OK, a real need beats my theoretical worries :-) Consider me convinced. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-05-18 05:05 Message: Logged In: YES user_id=139309 I would use partial in situations where speed can matter (imap, commonly used event handlers, etc.), so a fast C implementation would be nice to have. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-27 09:03 Message: Logged In: YES user_id=113328 Yes, that looks like a significant speed improvement :-) I was basing my assumptions on the comments made in the PEP. Sorry. But I still wonder if having the implementation in Python wouldn't be better from a maintenance point of view. (As well as all the arguments about usefulness as sample code, ability to backport, etc etc, that have come up on python-dev regarding moving other Python library modules into C...). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-27 03:05 Message: Logged In: YES user_id=55188 Python-version (function) ... 1.19 2.69 Python-version (class) ... 2.61 2.38 C-version ... 0.50 0.37 (former value is for 100000 instanciations and latter is for 100000 calls.) And, C version have a facility that changing attributes after the instantiation that is supported by class version only. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-04-26 20:30 Message: Logged In: YES user_id=113328 Why implement this in C? I can't imagine that the performance improvement will be that significant. A pure Python module in the standard library seems to me to be a far better idea. As the PEP says, "the case for a built-in coded in C is not very strong". And a Python module is good self-documentation. I prefer the function version suggested in the PEP (credited to Carl Banks) over the class-based one. You need to take a little care to avoid capturing argument names: def partial(*args, **kwds): def callit(*moreargs, **morekwds): kw = kwds.copy() kw.update(morekwds) return args[0](*(args[1:]+moreargs), **kw) return callit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470 From noreply at sourceforge.net Tue Aug 3 22:37:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 23:03:46 2004 Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff support, diff.py s/b/s HTML option Message-ID: Patches item #914575, was opened at 2004-03-11 17:50 Message generated for change (Comment added) made by dmgass You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Dan Gass (dmgass) Assigned to: Nobody/Anonymous (nobody) Summary: difflib side by side diff support, diff.py s/b/s HTML option Initial Comment: lib/difflib.py: Added support for generating side by side differences. Intended to be used for generating HTML pages but is generic where it can be used for other types of markup. tools/scripts/diff.py: Added -m option to use above patch to generate an HTML page of side by side differences between two files. The existing -c option when used with the new -m option controls whether contextual differences are shown or whether the entire file is displayed (number of context lines is controlled by existing -l option). NOTES: (1) Textual context diffs were included as requested. In addition, full and contextual HTML side by side differences (that this patch generated) are also included to assist in analyzing the differences and showing an example. (2) If this functionality is worthy of inclusion in the standard python distribution, I am willing to provide more documentation or make modifications to change the interface or make improvements. (3) When using Internet Explorer some font sizes seem to skew things a bit. Generally I've found the "smallest" to work best. If someone knows why, I'd be interested in making any necessary adjustments in the generated HTML. ---------------------------------------------------------------------- >Comment By: Dan Gass (dmgass) Date: 2004-08-03 15:37 Message: Logged In: YES user_id=995755 Is this patch being considered for going into Python 2.4 (and hence being checked into an alpha release)? FWIW, Tim Peters was +1 in favor of having this functionality in Python (even before the API was significantly enhanced) before washing his hands of it. I'd be interested in knowing whether this is going into 2.4, being shelved until the next release or whether the development/distribution of this functionlity should be moved to its own project. I'm getting a little anxious because I know an alpha release is in the works this week but I don't know how many more opportunities we have beyond that for 2.4. (I'm assuming there will be a long time before the next one.) Are there any more outstanding issues with it that need to be resolved? I am currently under the assumption no one has any objections or further recommendations. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-29 15:10 Message: Logged In: YES user_id=995755 > Rather than spending time on performance measurement, it is > best to focus on other goals. Aim for the smallest amount > of code, the neatest output, greatest ease of use, and the > simplest way to change the output appearance. Noted. > The size of the docs is one metric of ease of use. Ideally, > it would take a paragraph or two to explain. So far I've patched the libdifflib.tex file with about that amount of material. It details the "out-of-box" methods for generating HTML side by side differences. It does not address templates that we are leaving public to adjust the output. Should the documentation be left simple with just a reference to the doc string documentation within the module for further information about using the templates to adjust the output? > Also, write some sample code that produces a different > output appearance (XML for example). How easy was it to > do. The _mdiff() function could be used by those interested in doing side by side diffs with other markup such as XML. Previously you had mentioned that we should hide this function for now so we can reserve the right to change the interface. Truthfully I did not mind this decision because I don't think there is much need for it and it does avoid alot of documentation work to explain how to use it :-) > The goal is to focus the code into three parts: the > underlying ndiff, converting ndiff to side-by-side, and > output formatting. 1) ndiff() is what it is and I had no need to change it. 2) converting ndiff() to side-by-side is handled (and packaged neatly) by _mdiff(). The code in my opinion is well written and well commented. It is not public code so documentation for the python manuals is not required. 3) There has been a great deal of discussion regarding output formatting (early on a fair amount of it was done through private emails, but as of late everything is being logged here). IMHO I think the interface has shaped up very well, but I am still open for more suggestions. To date most of the feedback I have gotten is on the API and the output. I haven't heard much about the code. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-29 14:37 Message: Logged In: YES user_id=80475 Rather than spending time on performance measurement, it is best to focus on other goals. Aim for the smallest amount of code, the neatest output, greatest ease of use, and the simplest way to change the output appearance. The size of the docs is one metric of ease of use. Ideally, it would take a paragraph or two to explain. Also, write some sample code that produces a different output appearance (XML for example). How easy was it to do. The goal is to focus the code into three parts: the underlying ndiff, converting ndiff to side-by-side, and output formatting. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-29 12:13 Message: Logged In: YES user_id=995755 I think we are getting very close to having something for the next alpha release for Python 2.4. One exception is the last patch update I used a list comprehension that calls a function for every line of text. I'm thinking I should have called the function with the list and have it pass back a newly constructed list. To be sure which is the better way I want to do a performance measurement. I also would like to measure performance with and without "smarttabs". If it does not cost much I might be in favor of eliminating the option and just doing "smarttabs" all the time. In addition to performance degredation it would eliminate the ability to doing straight tab for spaces substitution (is this bad?). ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-29 09:32 Message: Logged In: YES user_id=995755 Updated the patch as follows: 1) Now handles expanding tabs and representing them with an appropriate HTML representation. 2) moved default prefix to class-level NOTES N1) See _libdifflib_tex_UPDATE.html and test_difflib_expect.html for an example of how tab differences get rendered. N2) I've attached the patch (you will also need the new file test_difflib_expect.html). I've zipped the patched code as well as example side by side differences of the patch. Diffs ending with _UPDATE.html show differences between the patched code and the last version of the patched code (what I've done since my last posting). Diffs ending with _PATCH.html show differences between the patched code and what I obtained from CVS a couple weeks back: python/python/dist/src/Lib/difflib.py -- rev 1.21 python/python/dist/src/Tools/scripts/diff.py -- rev 1.2 python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10 python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-28 17:41 Message: Logged In: YES user_id=764593 If you're dealing with tabs anywhere except at the start of a line, then you probably can't solve it in a general way -- tabstops become variable. If you're willing to settle for fixed-width tabstops (as on old typewriters, still works in some environments, works fine in tab-initial strings) then tab="        " Does everything you want in a single variable for tab-initial, and has all the information you need for fancy tab-internal processing (which I don't recommend). ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-28 17:02 Message: Logged In: YES user_id=995755 For the case where you instantiate HtmlDiff saying you want tabs expanded it will insert non-breaking space(s) up to the next tab stop. For the case where you do NOT specify tab expansion it will substitute one non-breakable space unless you override it with a different string (where you could choose 3,4, or 8 spaces). We could make 3,4, or 8 spaces the default but it makes it more complex because it would require two overridable class-level members ... spaces_per_tab = 8 tab_space = ' ' ... and the post processing would look like ... return s.replace('\t',self.tab_space*self.spaces_per_tab) ... and the pre-processing setup in the constructor would need to override the class-level member used for the post processing: self.spaces_per_tab=1 We could also use a special character for tabs. We could even attempt to use a combination of nbsp and a special character to show the tab stops. I'd need to play with re's to do that. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-28 16:36 Message: Logged In: YES user_id=764593 Are you saying that the default will replace tabs with a single non-breaking space? Not 3-4, as in many programming environments, or 8 as in standard keyboard, but 1? No objections other than that. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-28 14:39 Message: Logged In: YES user_id=995755 Unless I hear opposing arguments I will be updating the patch to handle tabs and to change the default prefix to be class-level either tonight or tommorow night. I plan on adding both pre and post processing to handle tabs. Preprocessing will be controlled by an an optional keyword argument in the HtmlDiff constructor specifying the number of spaces per tab stop. If absent or None is passed, no preprocessing will occur. Otherwise the tabs in each line of text will be expanded to the specified tab stop spacing (note, I will use the expandtabs() string method but will convert the resulting expanded spaces back into tabs so they get handled by post processing). Post processing will always occur. Any tabs remaining in the HTML markup will be substituted with the contents of a class-level variable (which can be overridden). By default, this variable will be set to ' ' These two changes will allow tab expansion to the correct tab stop without sacrificing the ability to see differences in files where tabs were converted to spaces or vice versa. It also provides a mechanism where by default, tabs are reasonably represented (or can be easily changed to your custom representation). ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-27 12:25 Message: Logged In: YES user_id=995755 You can replace tabs with markup by overriding format_line(). The disadvantage is that doing smart replacements (such as expandtabs() does) is more difficult because there could already be markup in there which doesn't count toward the tab stops. You can accomplish Walter's substition easily by overriding format_line(). This substitution cannot be done at the front end because the markup will be escaped and displayed. I'm seeing this as a supporting argument for making the tab filtering optional on the front end (dependent on how much of a performance hit it is to do it all the time). I intend on making the default prefix class-level so that different HtmlDiff instances share (and increment) the same value to avoid anchor name conflicts between two tables placed on the same HTML page. Jim, does that help clarify? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-07-27 11:28 Message: Logged In: YES user_id=89016 Formatting one line for output should be the job of an overwrittable method. This makes it possible to implement various tab replacement schemes and possibly even syntax highlighting. (BTW, I'd like my tabs to be replaced by ·  ) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 10:12 Message: Logged In: YES user_id=764593 Your tab solution sounds as good as any. I'm not sure I understand your intent with the default context. module-level is shared. class-level is shared unless/until assigned. instance-level (including "set by constructor") lets different HtmlDiff have different values. ---------------------------------------------------------------------- Comment By: Dan Gass (dmgass) Date: 2004-07-27 09:49 Message: Logged In: YES user_id=995755 I am considering making an optional argument to the constructor for specifying tab indentation. If nothing was passed it defaults to not handling tabs (better performance). If a number is passed, the string sequences (lists of lines) would be wrapped with a generator function to convert the tabs in each line with the expandtabs string method. The other option is to expand tabs all the time. If one is going to handle tabs it must be done on the input because once it is processed (markup added) the algorithm for expanding tabs becomes really compilicated. Any opinions regarding these options are welcome. I think I should change the default prefix (_default_prefix) to be a class member rather than initialize it with the constructor. (The default prefix is used to generate unique anchor names so there are no conflicts between multiple tables on the same HTML page). I'm leaning this way because a user may create separate instances of HtmlDiff (to have different ndiff or tab settings) but place the tables on the same page. If I left it the hyperlinks in the second table would jump to the first table. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 09:11 Message: Logged In: YES user_id=764593 Technically, HTML treats all whitespace (space, tab, newline, carriage return, etc) as interchangable with a single space, except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Aug  3 23:15:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug  3 23:15:50 2004
Subject: [Patches] [ python-Patches-655421 ] commands.py for Windows
Message-ID: 

Patches item #655421, was opened at 2002-12-17 13:30
Message generated for change (Settings changed) made by zopezen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=655421&group_id=5470

Category: Library (Lib)
Group: Python 2.1.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Andy McKay (zopezen)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands.py for Windows

Initial Comment:
The commands.py  module claims to only work on 
posix, I really don't see why that should be case. 
The only issue is the use of { ;} in the command 
sent to popen, but that's just a matter of changing 
the command for the os. Simple.

If accepted there should be a documentation 
change as well, but not sure where that is.

Tested on Win2k using Python 2.1.3

----------------------------------------------------------------------

Comment By: Andy McKay (zopezen)
Date: 2002-12-18 10:03

Message:
Logged In: YES 
user_id=166142

Oops, I have an ls exectuable on my box so I didn't 
notice that in testing. It would be simple to just parse 
the results of "dir file" though.

I'm not sure what to do about Win9x or WinME though, 
its clear I'll think a little harder about this one. 

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2002-12-18 01:44

Message:
Logged In: YES 
user_id=113328

Surely getstatus(file) won't work, as Windows doesn't have 
a "ls" command?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-12-17 19:40

Message:
Logged In: YES 
user_id=31435

Just noting that this doesn't work on Win95, Win98, 
Win98SE, or Win ME -- command.com (their native shell) 
doesn't support any way to redirect stderr.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=655421&group_id=5470
From zachariahcharles_ni at act.bm  Wed Aug  4 02:24:06 2004
From: zachariahcharles_ni at act.bm (zachariahcharles_ni@act.bm)
Date: Wed Aug  4 02:23:08 2004
Subject: [Patches] Make $472
Message-ID: 

Hello,

We sent you an email a while ago, because you now qualify for a new mortgage.
You could get $300,000 for as little as $700 a month!
Bad credit is no problem, you can pull cash out or refinance.

Please click on this link for free consultation by a mortgage broker:
http://www.hgkkdc.com/

Best Regards,
Jamie Higgs

No thanks: http://www.hgkkdc.com/r1

---- system information ----
more case host store this generic applications To 
collating identification applications The its element updated technologies

relevant depending publish call mistake presented architecture inferred


From robertablevins_ay at cc.jyu.fi  Wed Aug  4 03:10:39 2004
From: robertablevins_ay at cc.jyu.fi (Roberta Blevins)
Date: Wed Aug  4 02:47:51 2004
Subject: [Patches] Hey I just read your email..
Message-ID: <198e01c479bf$ea51c95f$b0a4f2e7@bedlfibus>

Hello,

Carol wanted me to tell you about this place.

http://aucbimo.info/prime/Munsuwest/index.htm

Ensure that you visit the link in 24 hrs to confirm your eligibility. 

Best Regards,
Marie Frye, Account Manager


















National Park Service officials went ahead with the reopening plan despite warnings of terrorist threats to the New York Stock Exchange in lower Manhattan and to the World Bank and International Monetary Fund headquarters in Washington, D.C. "I think it's significant that, despite the raising of the alert levels, we are still going ahead with the reopening," Assistant Interior Secretary Craig Manson said Monday. "I think it shows the world that liberty cannot be intimidated."  The new warnings did not merit any delay in the reopening of the 117-year-old statue, said Larry Parkinson, the Interior Department's deputy assistant secretary for law enforcement and security. "We were getting ramped up for it and already had measures in place that were absolutely appropriate for an orange level of security," Parkinson said.Orange is the second-highest on the Department of Homeland Security's color-coded scale of five threat levels. Most of the nation is at yellow, the middle level.On Sunday, Mayor Michael Bloomberg said the new terrorist alert for Washington, D.C., New York and New Jersey stemmed from intelligence suggesting car or truck bomb attacks.Since shortly after September 11, visitors to Liberty and Ellis islands have been passing through airport-type security checks before boarding ferries at lower Manhattan's Battery Park. 


From noreply at sourceforge.net  Wed Aug  4 06:41:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 06:42:05 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-12 00:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 06:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 22:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 22:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 21:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 19:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-29 00:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 00:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 23:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 21:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 19:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 18:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 17:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 16:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 16:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 08:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 15:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 17:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 06:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 22:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 18:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 18:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 17:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 17:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 15:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 15:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 13:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 15:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 21:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 11:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 11:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 08:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 20:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 20:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 08:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 16:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 06:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 15:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 06:48:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 06:48:49 2004
Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support
Message-ID: 

Patches item #890203, was opened at 2004-02-03 22:30
Message generated for change (Comment added) made by jparise
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Parise (jparise)
Assigned to: Nobody/Anonymous (nobody)
Summary: DragonFly BSD support

Initial Comment:
I spent some time building a simple little patch that
gets Python up and running under DragonFly BSD.  At the
moment, DragonFly (as a platform) is nearly identical
to FreeBSD (from which is was forked), so the generated
the patch was largely mechanical.

I'll continue to make efforts to support Python on
DragonFly should things become more complicated.

The only known issue is a test case failure for
test_fcntl.  I don't know whether this failure is
unique to DragonFly at this time.  I'll investigate
that soon.

This patch is valid for DragonFly 1.0-CURRENT using
either GCC 2.95.4 or GCC 3.3.3 20040126.

----------------------------------------------------------------------

>Comment By: Jon Parise (jparise)
Date: 2004-08-03 21:48

Message:
Logged In: YES 
user_id=485579

That's strange.  I just built Python HEAD under DragonFly
1.1-CURRENT.  I've updated the patch to reflect the latest
changes to the Python repository.

What configure arguments are you using?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-24 21:33

Message:
Logged In: YES 
user_id=55188

I got massive errors while compiling some extension modules.
(DragonflyBSD 1.0A, python HEAD as of today)

ld build/temp.dragonfly-1.0A-RELEASE-i386-2.4/dlmodule.o
-L/usr/local/lib -o
build/lib.dragonfly-1.0A-RELEASE-i386-2.4/dl.so
/usr/libexec/binutils212/elf/ld: warning: cannot find entry
symbol _start; defaulting to 08048074
build/temp.dragonfly-1.0A-RELEASE-i386-2.4/dlmodule.o: In
function `dl_call':
/home/perky/python/Modules/dlmodule.c:82: undefined
reference to `PyTuple_Size'
/home/perky/python/Modules/dlmodule.c:84: undefined
reference to `PyExc_TypeError'
/home/perky/python/Modules/dlmodule.c:84: undefined
reference to `PyErr_SetString'
/home/perky/python/Modules/dlmodule.c:87: undefined
reference to `PyTuple_GetItem'
/home/perky/python/Modules/dlmodule.c:88: undefined
reference to `PyString_Type'
/home/perky/python/Modules/dlmodule.c:88: undefined
reference to `PyString_Type'
/home/perky/python/Modules/dlmodule.c:88: undefined
reference to `PyType_IsSubtype'


----------------------------------------------------------------------

Comment By: Jon Parise (jparise)
Date: 2004-03-14 18:43

Message:
Logged In: YES 
user_id=485579

The test_fcnlt failure has been corrected in the latest patch.

----------------------------------------------------------------------

Comment By: Jon Parise (jparise)
Date: 2004-03-04 23:26

Message:
Logged In: YES 
user_id=485579

Updated the patch against the latest Python 2.4a (cvs) code.

----------------------------------------------------------------------

Comment By: Jon Parise (jparise)
Date: 2004-02-04 16:00

Message:
Logged In: YES 
user_id=485579

Yes, I'm comfortable with that.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-02-04 14:36

Message:
Logged In: YES 
user_id=21627

Are you willing to act as a maintainer and contact point for
the Dragonfly port?

----------------------------------------------------------------------

Comment By: Jon Parise (jparise)
Date: 2004-02-03 22:32

Message:
Logged In: YES 
user_id=485579

Also, attached in the generated IN.py Lib/plat-dragonfly1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 07:08:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 07:10:14 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-04 01:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 00:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 16:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 15:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 18:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 18:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 07:59:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 08:00:01 2004
Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing
Message-ID: 

Patches item #1002085, was opened at 2004-08-02 09:43
Message generated for change (Comment added) made by boredzo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mac-arena the Bored Zo (boredzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: O(1) xrange membership testing

Initial Comment:
this patch applies to anonymous CVS as of 2004-08-02 at 07:
54:58 PDT.

it adds O(1) membership testing; for example:

Python 2.4a1+ (#2, Aug  2 2004, 09:11:43) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on 
darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> sys.maxint
2147483647
>>> sys.maxint in xrange(sys.maxint)
False

in current CVS, this would take untold hours to complete 
(because Python arrives at this answer by iterating on the 
sequence). this patch adds a __contains__ method to the 
xrange object which examines the xrange's pattern and 
determines the correct answer instantly based on that pattern.

----------------------------------------------------------------------

>Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-03 22:59

Message:
Logged In: YES 
user_id=711099

__contains__ never fails anymore; it now falls back on the old 
behaviour of iterating on the sequence when the object being tested 
for membership is not a Python int. (I didn't know it did that before. 
another cool Python feature. :)

also, the new patch is current with anonymous CVS as of 2004-08-03 
at 10:47:53 PM PDT.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 05:50

Message:
Logged In: YES 
user_id=21627

This patch is incorrect. Currently,

"s" in xrange(3,4)

gives False. With the patch, it raises an exception.

Your patch should only take integer objects into account. 
Any other object might have an __eq__ that makes it compare
equal to a number from the range.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-02 12:42

Message:
Logged In: YES 
user_id=711099

found and fixed a bug: the new __contains__ method didn't check for 
an exception from PyInt_AsLong.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-02 11:25

Message:
Logged In: YES 
user_id=711099

heh, no I didn't check the checkbox. thanks for reminding me. :)

the original patch didn't include unit tests, but that is a good idea. ;) 
so I've added changes to test_xrange.py.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-02 10:28

Message:
Logged In: YES 
user_id=580910

You forgot to add the patch (did you check the checkbox?).

BTW. Does your patch include unittests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470
From Norton_AntiVirus_Gateways at cmcltd.com  Wed Aug  4 08:45:38 2004
From: Norton_AntiVirus_Gateways at cmcltd.com (Norton_AntiVirus_Gateways@cmcltd.com)
Date: Wed Aug  4 08:35:20 2004
Subject: [Patches] CMC MAIL GATEWAY ALERT
Message-ID: 

A Virus was detected in the mail sent by you.
The message has been rejected.


--- Scan information follows ---

Result: Virus Detected
Virus Name: W32.Lovgate.R@mm
File Attachment: document.zip
Attachment Status: deleted

--- Original message information follows ---

From: patches@python.org
To: vijaya@cmcltd.com
Date: Wed, 4 Aug 2004 11:43:02 +0530
Subject: Mail Transaction Failed
Message-Id: 
Received: from python.org ([172.16.16.97])
 by navgw.cmcltd.com (NAVGW 2.5.1.6) with SMTP id M2004080411533912959
 for ; Wed, 04 Aug 2004 11:53:39 +0530
From noreply at sourceforge.net  Wed Aug  4 14:51:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 14:51:26 2004
Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing
Message-ID: 

Patches item #1002085, was opened at 2004-08-02 12:43
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mac-arena the Bored Zo (boredzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: O(1) xrange membership testing

Initial Comment:
this patch applies to anonymous CVS as of 2004-08-02 at 07:
54:58 PDT.

it adds O(1) membership testing; for example:

Python 2.4a1+ (#2, Aug  2 2004, 09:11:43) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on 
darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> sys.maxint
2147483647
>>> sys.maxint in xrange(sys.maxint)
False

in current CVS, this would take untold hours to complete 
(because Python arrives at this answer by iterating on the 
sequence). this patch adds a __contains__ method to the 
xrange object which examines the xrange's pattern and 
determines the correct answer instantly based on that pattern.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-04 08:51

Message:
Logged In: YES 
user_id=31435

You should know that xrange objects *used* to have 
efficient "in" testing, and a whole bunch of other features 
too.  They were deliberately removed in 2.2a1.  Search 
for "xrange" in your Python NEWS file.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-04 01:59

Message:
Logged In: YES 
user_id=711099

__contains__ never fails anymore; it now falls back on the old 
behaviour of iterating on the sequence when the object being tested 
for membership is not a Python int. (I didn't know it did that before. 
another cool Python feature. :)

also, the new patch is current with anonymous CVS as of 2004-08-03 
at 10:47:53 PM PDT.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 08:50

Message:
Logged In: YES 
user_id=21627

This patch is incorrect. Currently,

"s" in xrange(3,4)

gives False. With the patch, it raises an exception.

Your patch should only take integer objects into account. 
Any other object might have an __eq__ that makes it compare
equal to a number from the range.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-02 15:42

Message:
Logged In: YES 
user_id=711099

found and fixed a bug: the new __contains__ method didn't check for 
an exception from PyInt_AsLong.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-02 14:25

Message:
Logged In: YES 
user_id=711099

heh, no I didn't check the checkbox. thanks for reminding me. :)

the original patch didn't include unit tests, but that is a good idea. ;) 
so I've added changes to test_xrange.py.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-02 13:28

Message:
Logged In: YES 
user_id=580910

You forgot to add the patch (did you check the checkbox?).

BTW. Does your patch include unittests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 14:59:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 15:00:13 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 08:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 01:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 00:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 16:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 15:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 18:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 18:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 16:00:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 16:01:44 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 19:35:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 19:35:20 2004
Subject: [Patches] [ python-Patches-1002085 ] O(1) xrange membership testing
Message-ID: 

Patches item #1002085, was opened at 2004-08-02 18:43
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Mac-arena the Bored Zo (boredzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: O(1) xrange membership testing

Initial Comment:
this patch applies to anonymous CVS as of 2004-08-02 at 07:
54:58 PDT.

it adds O(1) membership testing; for example:

Python 2.4a1+ (#2, Aug  2 2004, 09:11:43) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on 
darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys
>>> sys.maxint
2147483647
>>> sys.maxint in xrange(sys.maxint)
False

in current CVS, this would take untold hours to complete 
(because Python arrives at this answer by iterating on the 
sequence). this patch adds a __contains__ method to the 
xrange object which examines the xrange's pattern and 
determines the correct answer instantly based on that pattern.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 19:35

Message:
Logged In: YES 
user_id=21627

Ah, forgot/ignored that. Rejecting the patch because the
feature was deprecated.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 14:51

Message:
Logged In: YES 
user_id=31435

You should know that xrange objects *used* to have 
efficient "in" testing, and a whole bunch of other features 
too.  They were deliberately removed in 2.2a1.  Search 
for "xrange" in your Python NEWS file.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=711099

__contains__ never fails anymore; it now falls back on the old 
behaviour of iterating on the sequence when the object being tested 
for membership is not a Python int. (I didn't know it did that before. 
another cool Python feature. :)

also, the new patch is current with anonymous CVS as of 2004-08-03 
at 10:47:53 PM PDT.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 14:50

Message:
Logged In: YES 
user_id=21627

This patch is incorrect. Currently,

"s" in xrange(3,4)

gives False. With the patch, it raises an exception.

Your patch should only take integer objects into account. 
Any other object might have an __eq__ that makes it compare
equal to a number from the range.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-02 21:42

Message:
Logged In: YES 
user_id=711099

found and fixed a bug: the new __contains__ method didn't check for 
an exception from PyInt_AsLong.

----------------------------------------------------------------------

Comment By: Mac-arena the Bored Zo (boredzo)
Date: 2004-08-02 20:25

Message:
Logged In: YES 
user_id=711099

heh, no I didn't check the checkbox. thanks for reminding me. :)

the original patch didn't include unit tests, but that is a good idea. ;) 
so I've added changes to test_xrange.py.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-02 19:28

Message:
Logged In: YES 
user_id=580910

You forgot to add the patch (did you check the checkbox?).

BTW. Does your patch include unittests?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1002085&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 19:37:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 19:38:00 2004
Subject: [Patches] [ python-Patches-941229 ] Allow any encodings other than
	latin-1 in interactive interp
Message-ID: 

Patches item #941229, was opened at 2004-04-24 18:49
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Hye-Shik Chang (perky)
Summary: Allow any encodings other than latin-1 in interactive interp

Initial Comment:
Python interactive interpreter uses ISO-8859-1 for
parsing incoming codes from sys.stdin whatever
sys.stdin.encoding is.
This patch allows to use locale-aware encodings other
than ISO-8859-1 in interactive sessions.

eg.

Before:

>>> u'한글'  # (U+D55C, U+AE00)
u'\xc7\xd1\xb1\xdb'

After:

>>> u'한글'
u'\ud55c\uae00'


The attached sample implementation fall backs to
ISO-8859-1 for any non-memory errors such as
UnicodeDecodeError. So if you use ascii or iso-8859-1,
you'll not able to find difference. It intended to
affect to non-latin-1 encoding users.


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-08-05 02:37

Message:
Logged In: YES 
user_id=55188

Checked in/

Misc/NEWS 1.1069
Parser/tokenizer.c 2.76

Thanks for the review!


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-02 17:20

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply. You might consider removing
the error check for PyString_AsString - that function cannot
fail.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-08-02 15:53

Message:
Logged In: YES 
user_id=55188

I'd like to see some progression on this in upcoming 2.4a2.
Can you please give some comment on this? :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941229&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 22:17:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 22:17:54 2004
Subject: [Patches] [ python-Patches-1003535 ] Simple File fix for Windows
	Runtime incompatability
Message-ID: 

Patches item #1003535, was opened at 2004-08-04 16: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=1003535&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Schwartz (mdjeremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple File fix for Windows Runtime incompatability

Initial Comment:

Problem:

PyRun_SimpleFile - Using this function on Windows with
MSVC7 (VS .NET) causes a crash.

Reason: 

1)Pre built binaries link to msvcrt.dll. New version of
MSVC link to msvcrt71.dll. The FILE structure is
different across the two versions of runtime library. 

2) If python23.dll is rebuilt using the latest binary,
and issue exist where passing in FILE * still causes
the runtime library to throw an exception due to
running in the dll's context.

Solution:

Remove both of these problems by adding a new function
that only takes the filename (future maybe fopen flags)
and have the dll open the file itself and pass it on.

New function added to pythonrun.c and pythonrun.h

int
PyRun_SimpleFileWithOpen(const char *filename)

Takes just the file name, opens the file and then pass
it on.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003535&group_id=5470
From noreply at sourceforge.net  Wed Aug  4 23:53:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug  4 23:53:50 2004
Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4
	implementation
Message-ID: 

Patches item #1000267, was opened at 2004-07-29 13:52
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: chads (cjschr)
Assigned to: Nobody/Anonymous (nobody)
Summary: A BSD-style wait4 implementation

Initial Comment:
A BSD-style wait4 implementation.

Using existing code from the posixmodule.c and
resource.c files,
I threw together a patch that implements the wait4
function.

This function is similar to waitpid, but it also
returns usage information
about the child process.

wait4(pid, options) -> (pid, status, rusage)

It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes
using
Python-2.3.4.

The patch may need some fine tuning.

Thanks
Chad

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-04 16:53

Message:
Logged In: YES 
user_id=2772

You should also add code to the test suite to test wait4
when it is available.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 01:23:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 01:23:19 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-04 16:23
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=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 03:27:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 03:27:32 2004
Subject: [Patches] [ python-Patches-1003693 ] Fix for 1002475 (Feedparser
	not handling \r\n correctly)
Message-ID: 

Patches item #1003693, was opened at 2004-08-05 13:27
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=1003693&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for 1002475 (Feedparser not handling \r\n correctly)

Initial Comment:
Python 2.4a1/Anon CVS of 5 Aug 2004.  WinXP SP1, not
that that matters.

This is a patch to fix bug:

[ 1002475 ] email message parser doesn't handle \r\n
correctly
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475

Basically, FeedParser does a rstrip() on the last
header value, but not any of the others.  Given that
RFC822 wants the headers to end with \r\n, it's likely
that most will, and this means that all the headers
except for the last end with \r.  This one line patch
just does the extra rstrip.

Note that you might want to implement the fix yourself
- it doesn't fit on a line, and so it's wrapped in an
ugly way - maybe you can think of something prettier :)
 This does fix the problem, though (here, at least,
using the test case outlined in the bug report).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 03:46:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 03:47:00 2004
Subject: [Patches] [ python-Patches-1003693 ] Fix for 1002475 (Feedparser
	not handling \r\n correctly)
Message-ID: 

Patches item #1003693, was opened at 2004-08-05 13:27
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Fix for 1002475 (Feedparser not handling \r\n correctly)

Initial Comment:
Python 2.4a1/Anon CVS of 5 Aug 2004.  WinXP SP1, not
that that matters.

This is a patch to fix bug:

[ 1002475 ] email message parser doesn't handle \r\n
correctly
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475

Basically, FeedParser does a rstrip() on the last
header value, but not any of the others.  Given that
RFC822 wants the headers to end with \r\n, it's likely
that most will, and this means that all the headers
except for the last end with \r.  This one line patch
just does the extra rstrip.

Note that you might want to implement the fix yourself
- it doesn't fit on a line, and so it's wrapped in an
ugly way - maybe you can think of something prettier :)
 This does fix the problem, though (here, at least,
using the test case outlined in the bug report).

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 13:46

Message:
Logged In: YES 
user_id=552329

Attaching new patch, because that one breaks one of the
tests.  The rstrip() needs to be rstrip('\r\n') or it strips
other whitespace that isn't allowed there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 03:48:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 03:48:50 2004
Subject: [Patches] [ python-Patches-1003693 ] Fix for 1002475 (Feedparser
	not handling \r\n correctly)
Message-ID: 

Patches item #1003693, was opened at 2004-08-05 13:27
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Fix for 1002475 (Feedparser not handling \r\n correctly)

Initial Comment:
Python 2.4a1/Anon CVS of 5 Aug 2004.  WinXP SP1, not
that that matters.

This is a patch to fix bug:

[ 1002475 ] email message parser doesn't handle \r\n
correctly
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475

Basically, FeedParser does a rstrip() on the last
header value, but not any of the others.  Given that
RFC822 wants the headers to end with \r\n, it's likely
that most will, and this means that all the headers
except for the last end with \r.  This one line patch
just does the extra rstrip.

Note that you might want to implement the fix yourself
- it doesn't fit on a line, and so it's wrapped in an
ugly way - maybe you can think of something prettier :)
 This does fix the problem, though (here, at least,
using the test case outlined in the bug report).

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 13:48

Message:
Logged In: YES 
user_id=552329

Also attached is a patch for test_email.py.  This adds two
new tests (which fail before the FeedParser.py patch, and
pass afterwards).

The first tests that the \r\n characters are correctly removed.
The second is a copy of an existing test to check
continuations with whitespace, but checks if it works with
the continuation as the last header.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 13:46

Message:
Logged In: YES 
user_id=552329

Attaching new patch, because that one breaks one of the
tests.  The rstrip() needs to be rstrip('\r\n') or it strips
other whitespace that isn't allowed there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 04:09:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 04:09:13 2004
Subject: [Patches] [ python-Patches-1003700 ] add socketpair function to
	socket module
Message-ID: 

Patches item #1003700, was opened at 2004-08-05 02:09
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=1003700&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Nobody/Anonymous (nobody)
Summary: add socketpair function to socket module

Initial Comment:
Adds a socketpair() function to the socketmodule.c.  
The function returns two socket objects.

Contains some simple unit tests that check the return
value from socketpair is actually two functioning sockets.

Outstanding question is whether the family, type, proto
arguments should be kwargs as per socket() function, or
positional as per fromfd() function.  If kwargs, then
it is arguable that the fromfd() arguments should be
changed (in another patch).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 04:09:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 04:10:04 2004
Subject: [Patches] [ python-Patches-1003693 ] Fix for 1002475 (Feedparser
	not handling \r\n correctly)
Message-ID: 

Patches item #1003693, was opened at 2004-08-05 13:27
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Fix for 1002475 (Feedparser not handling \r\n correctly)

Initial Comment:
Python 2.4a1/Anon CVS of 5 Aug 2004.  WinXP SP1, not
that that matters.

This is a patch to fix bug:

[ 1002475 ] email message parser doesn't handle \r\n
correctly
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475

Basically, FeedParser does a rstrip() on the last
header value, but not any of the others.  Given that
RFC822 wants the headers to end with \r\n, it's likely
that most will, and this means that all the headers
except for the last end with \r.  This one line patch
just does the extra rstrip.

Note that you might want to implement the fix yourself
- it doesn't fit on a line, and so it's wrapped in an
ugly way - maybe you can think of something prettier :)
 This does fix the problem, though (here, at least,
using the test case outlined in the bug report).

----------------------------------------------------------------------

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 14:09

Message:
Logged In: YES 
user_id=552329

Second test was in the wrong place, so moving.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 13:48

Message:
Logged In: YES 
user_id=552329

Also attached is a patch for test_email.py.  This adds two
new tests (which fail before the FeedParser.py patch, and
pass afterwards).

The first tests that the \r\n characters are correctly removed.
The second is a copy of an existing test to check
continuations with whitespace, but checks if it works with
the continuation as the last header.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 13:46

Message:
Logged In: YES 
user_id=552329

Attaching new patch, because that one breaks one of the
tests.  The rstrip() needs to be rstrip('\r\n') or it strips
other whitespace that isn't allowed there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 08:51:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 08:51:33 2004
Subject: [Patches] [ python-Patches-972991 ] fix build of docs in info format
Message-ID: 

Patches item #972991, was opened at 2004-06-15 07:47
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Matthias Klose (doko)
Summary: fix build of docs in info format

Initial Comment:
one of those a workaround in py2texi.el (verbatim
environments are processed before comments)


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2004-08-05 08:51

Message:
Logged In: YES 
user_id=60903

fixed in Doc/dist/dist.tex 1.82
fixed in Doc/lib/libfuncs.tex 1.170

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 15:10

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2004-07-11 09:56

Message:
Logged In: YES 
user_id=60903

> need more documentation

???

- the libfuncs.tex patch fixes wrong latex.
- the dist.tex patch avoid uncommenting the verbose
environment by py2texi.


----------------------------------------------------------------------

Comment By: alan johnson (chomo)
Date: 2004-07-01 23:40

Message:
Logged In: YES 
user_id=943591

need more documentation

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972991&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 09:56:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 09:56:14 2004
Subject: [Patches] [ python-Patches-955928 ] use
	PyOS_ReadlineFunctionPointer in non-interractive input 
Message-ID: 

Patches item #955928, was opened at 2004-05-18 15:41
Message generated for change (Comment added) made by greglielens
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Lielens (greglielens)
>Assigned to: Michael Hudson (mwh)
Summary: use PyOS_ReadlineFunctionPointer in non-interractive input 

Initial Comment:
Extend the control provided by
PyOS_ReadlineFunctionPointer to non-interractive
inputs. In addition, initialize
PyOS_ReadlineFunctionPointer to the default input
function, so that it can be retrieved by extern code
(allowing for embedding the old input function and
modifying it). Readline Module changed accordingly
(only modify PyOS_ReadlineFunctionPointer to
call_readline if input is interractive).
This was neccessary to modify the input behavior of
PyRun_InteractiveLoop, in case input is not interractive...
The application is a python driven parallel framework
using MPI, where the interractive process broadcast the
input lines to the non-interractive processes, who
listen...but other applications may benefit also.
patched: Modules/readline.c
               Parser/myreadline.c

----------------------------------------------------------------------

>Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 09:56

Message:
Logged In: YES 
user_id=1044428

I updated the patch to python current CVS, and do similar
modification in /Python/bltinmodule.c for builtin_raw_input
fonction.
builtin_raw_input now call PyOS_Readline when  stdin and
stdout objects are file, regardless if they are tty or not.
This one was forgotten in the first version of the patch,
and is needed to be able to use the same broadcasting
technique for parrallel interractive session when using
IPython. I now think that all functions implementing
possibly interractive input have been patched...
All regression tests pass except test_grp and test_pwd, but
those fail exactly the same way (KeyError) with non-patched
cvs...
Any chance to have this considered for 2.4?
Regards,
Greg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 11:29:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 11:29:49 2004
Subject: [Patches] [ python-Patches-995939 ] Avoid calling tp_compare with
	different types
Message-ID: 

Patches item #995939, was opened at 2004-07-22 14:14
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&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: Avoid calling tp_compare with different types

Initial Comment:
C implementations of the tp_compare slot usually expect both of their 
arguments to have the type for which that slot is defined (this isn't 
documented anywhere that I can find, but many core types assume this, 
and extension authors are likely to do the same). A problem occurs if a 
user-defined nb_coerce slot (__coerce__) returns objects with different 
types. Avoid the problem by refusing to call a non-Python tp_compare 
unless the arguments have the same type. Indiscriminately calling 
tp_compare with different types is wrong as long as there are 
implementations that don't check the type of the second argument, but 
Python implementations should be allowed to receive a different type.

Other options for fixing the problem:
  - Make PyNumber_CoerceEx require that the results have the same 
type. This would prevent a user-defined __coerce__ from 
communicating an arbitrary object to a user-defined __cmp__. 
Furthermore, there are uses for coerce besides comparison, and those 
uses might not require identical types.
  - Change tp_compare implementations to check the type of the 
second argument. This might be the most desirable long-term solution, 
but as I understand it, tp_richcompare is preferred over tp_compare for 
new code, and old (current) code is likely assuming that the types are 
the same.

Addresses bug #980352


----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-05 09:29

Message:
Logged In: YES 
user_id=908995

The patch is intended to be complete, but it's certainly possible that I 
missed something. Every other call to tp_compare checks that the 
operands have the same type or the same compare function; the only 
exceptions are if one of operands passes PyInstance_Check or if it's 
_PyObject_SlotCompare (it's treated specially in try_3way_compare).

I'm actually more concerned about restricting too much than having 
missing something. The tests I wrote try to make sure that the 
user-visible changes are limited to the absence of a crash, but I'm not 
sure that I didn't accidently break some code that used to work.

Comparing subclasses of builtins to builtins still works, too. On line 599 
of the post-patch object.c, we see:

	/* If both have the same (non-NULL) tp_compare, use it. */
	if (f != NULL && f == w->ob_type->tp_compare) {
		c = (*f)(v, w);
		return adjust_tp_compare(c);
	}

which takes care of that case.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-08-03 09:36

Message:
Logged In: YES 
user_id=4771

Is your patch complete?  There seem to be a lot of places in object.c that call tp_compare slots.  Shouldn't we try to make sure that none of these places can ever be called with two different types?

It also looks like we have to do something special about a value of &_PyObject_SlotCompare in tp_compare, because this function from typeobject.c checks itself the type of its arguments and does specific things with them.  This should be thought about.

Moreover there is the issue of the user subclassing built-in types, e.g. PyInt_Type.tp_compare is capable of comparing different user subclasses of "int" for each other.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 12:22:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 12:22:36 2004
Subject: [Patches] [ python-Patches-1003861 ] Fix markup in concrete.tex
Message-ID: 

Patches item #1003861, was opened at 2004-08-05 10: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=1003861&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix markup in concrete.tex

Initial Comment:
A few minor changes:

  - "PyObject* o" -> "PyObject *o" to be consistent with the
     rest of the file
  - Correct markup for Py_True
  - Remove duplicate description of PyBool_Check


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003861&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 12:31:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 12:31:19 2004
Subject: [Patches] [ python-Patches-1003863 ] adds an index entry for
	__all__ to the tutorial
Message-ID: 

Patches item #1003863, was opened at 2004-08-05 10:31
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=1003863&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Clinton Roy (clintonroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: adds an index entry for __all__ to the tutorial

Initial Comment:
a one liner.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003863&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 13:11:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 13:11:30 2004
Subject: [Patches] [ python-Patches-955928 ] use
	PyOS_ReadlineFunctionPointer in non-interractive input 
Message-ID: 

Patches item #955928, was opened at 2004-05-18 14:41
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Lielens (greglielens)
Assigned to: Michael Hudson (mwh)
Summary: use PyOS_ReadlineFunctionPointer in non-interractive input 

Initial Comment:
Extend the control provided by
PyOS_ReadlineFunctionPointer to non-interractive
inputs. In addition, initialize
PyOS_ReadlineFunctionPointer to the default input
function, so that it can be retrieved by extern code
(allowing for embedding the old input function and
modifying it). Readline Module changed accordingly
(only modify PyOS_ReadlineFunctionPointer to
call_readline if input is interractive).
This was neccessary to modify the input behavior of
PyRun_InteractiveLoop, in case input is not interractive...
The application is a python driven parallel framework
using MPI, where the interractive process broadcast the
input lines to the non-interractive processes, who
listen...but other applications may benefit also.
patched: Modules/readline.c
               Parser/myreadline.c

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-05 12:11

Message:
Logged In: YES 
user_id=6656

A chance, yes.  I'm a bit loath to change this, as I have no
idea why things were done this way in the first place.  If
it's the traditional "no good reason", then I guess this can
go in...

Also, I think your patch is backwards and doesn't adhere to
the local style wrt tabs and spaces.

----------------------------------------------------------------------

Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 08:56

Message:
Logged In: YES 
user_id=1044428

I updated the patch to python current CVS, and do similar
modification in /Python/bltinmodule.c for builtin_raw_input
fonction.
builtin_raw_input now call PyOS_Readline when  stdin and
stdout objects are file, regardless if they are tty or not.
This one was forgotten in the first version of the patch,
and is needed to be able to use the same broadcasting
technique for parrallel interractive session when using
IPython. I now think that all functions implementing
possibly interractive input have been patched...
All regression tests pass except test_grp and test_pwd, but
those fail exactly the same way (KeyError) with non-patched
cvs...
Any chance to have this considered for 2.4?
Regards,
Greg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 13:21:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 13:21:22 2004
Subject: [Patches] [ python-Patches-955928 ] use
	PyOS_ReadlineFunctionPointer in non-interractive input 
Message-ID: 

Patches item #955928, was opened at 2004-05-18 14:41
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Lielens (greglielens)
Assigned to: Michael Hudson (mwh)
Summary: use PyOS_ReadlineFunctionPointer in non-interractive input 

Initial Comment:
Extend the control provided by
PyOS_ReadlineFunctionPointer to non-interractive
inputs. In addition, initialize
PyOS_ReadlineFunctionPointer to the default input
function, so that it can be retrieved by extern code
(allowing for embedding the old input function and
modifying it). Readline Module changed accordingly
(only modify PyOS_ReadlineFunctionPointer to
call_readline if input is interractive).
This was neccessary to modify the input behavior of
PyRun_InteractiveLoop, in case input is not interractive...
The application is a python driven parallel framework
using MPI, where the interractive process broadcast the
input lines to the non-interractive processes, who
listen...but other applications may benefit also.
patched: Modules/readline.c
               Parser/myreadline.c

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-05 12:21

Message:
Logged In: YES 
user_id=6656

Uh, no, scratch that: I think your attempt to upload a new
patch failed.  Try again?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 12:11

Message:
Logged In: YES 
user_id=6656

A chance, yes.  I'm a bit loath to change this, as I have no
idea why things were done this way in the first place.  If
it's the traditional "no good reason", then I guess this can
go in...

Also, I think your patch is backwards and doesn't adhere to
the local style wrt tabs and spaces.

----------------------------------------------------------------------

Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 08:56

Message:
Logged In: YES 
user_id=1044428

I updated the patch to python current CVS, and do similar
modification in /Python/bltinmodule.c for builtin_raw_input
fonction.
builtin_raw_input now call PyOS_Readline when  stdin and
stdout objects are file, regardless if they are tty or not.
This one was forgotten in the first version of the patch,
and is needed to be able to use the same broadcasting
technique for parrallel interractive session when using
IPython. I now think that all functions implementing
possibly interractive input have been patched...
All regression tests pass except test_grp and test_pwd, but
those fail exactly the same way (KeyError) with non-patched
cvs...
Any chance to have this considered for 2.4?
Regards,
Greg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 14:02:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 14:02:57 2004
Subject: [Patches] [ python-Patches-955928 ] use
	PyOS_ReadlineFunctionPointer in non-interractive input 
Message-ID: 

Patches item #955928, was opened at 2004-05-18 15:41
Message generated for change (Comment added) made by greglielens
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Lielens (greglielens)
Assigned to: Michael Hudson (mwh)
Summary: use PyOS_ReadlineFunctionPointer in non-interractive input 

Initial Comment:
Extend the control provided by
PyOS_ReadlineFunctionPointer to non-interractive
inputs. In addition, initialize
PyOS_ReadlineFunctionPointer to the default input
function, so that it can be retrieved by extern code
(allowing for embedding the old input function and
modifying it). Readline Module changed accordingly
(only modify PyOS_ReadlineFunctionPointer to
call_readline if input is interractive).
This was neccessary to modify the input behavior of
PyRun_InteractiveLoop, in case input is not interractive...
The application is a python driven parallel framework
using MPI, where the interractive process broadcast the
input lines to the non-interractive processes, who
listen...but other applications may benefit also.
patched: Modules/readline.c
               Parser/myreadline.c

----------------------------------------------------------------------

>Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 14:02

Message:
Logged In: YES 
user_id=1044428

I edited the patch to comply with the tab style (or hope so).
For the reverse, I used cvs diff -c and assumed it would
produce it in the correct order, is it not the case? Anyway,
here is the new patch... (If it is still reversed and you
have a special option for cvs diff to produce the patch in
correct order, I am very interrested! ;-) )

Regarding the origin of the tty test, it is done (at least
for the stdin) since the first revision that used a
mechanism similar to the current one
(PyOS_ReadlineFunctionPointer), and this was done by Guido
(r2.11)
The test was removed just after (r2.12, again guido),
and finally re-introduced in it's final form in revision
2.28, by loewis.
Maybe I can assign him so that he gives us a idea of the
intention of this, and his feeling about this patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 13:21

Message:
Logged In: YES 
user_id=6656

Uh, no, scratch that: I think your attempt to upload a new
patch failed.  Try again?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 13:11

Message:
Logged In: YES 
user_id=6656

A chance, yes.  I'm a bit loath to change this, as I have no
idea why things were done this way in the first place.  If
it's the traditional "no good reason", then I guess this can
go in...

Also, I think your patch is backwards and doesn't adhere to
the local style wrt tabs and spaces.

----------------------------------------------------------------------

Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 09:56

Message:
Logged In: YES 
user_id=1044428

I updated the patch to python current CVS, and do similar
modification in /Python/bltinmodule.c for builtin_raw_input
fonction.
builtin_raw_input now call PyOS_Readline when  stdin and
stdout objects are file, regardless if they are tty or not.
This one was forgotten in the first version of the patch,
and is needed to be able to use the same broadcasting
technique for parrallel interractive session when using
IPython. I now think that all functions implementing
possibly interractive input have been patched...
All regression tests pass except test_grp and test_pwd, but
those fail exactly the same way (KeyError) with non-patched
cvs...
Any chance to have this considered for 2.4?
Regards,
Greg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 17:36:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 17:36:46 2004
Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation
Message-ID: 

Patches item #980695, was opened at 2004-06-27 09:39
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470

Category: Core (C code)
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: efficient string concatenation

Initial Comment:
A wild idea that makes repeated string concatenations efficient without changing stringobject.c.

If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1.

But with some hacks ceval.c can know that.  Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME.  So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already).  If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory).

With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely.

As a side effect, other constructions like a+b+c+d+e+f also work in-place now.

The patch would do with a lot more comments.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-05 11:36

Message:
Logged In: YES 
user_id=6380

This can go in on two conditions:

1) That is clearly documented as a quality-of-implementation
issue, not a language feature

2) That it is not relied upon in the standard library (which
is shared with Jython)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-03 10:13

Message:
Logged In: YES 
user_id=6380

Not so fast, see python-dev.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-08-03 08:37

Message:
Logged In: YES 
user_id=99874

While I think CPython should get the patch, I *am* worried
about Jython (and Iron Python I suppose). In particular,
Samuele's plea to keep this out of the std library is likely
to be followed for a few months, then completely forgotten.
Perhaps we need some way to check, when running the test
suite, just how much dependence there is on this feature...
then there's at least be a way to *find* the bits where
people who didn't predate this change failed to use the
obscure ''.join() idiom that us oldtimers keep nagging about
.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2004-08-03 07:19

Message:
Logged In: YES 
user_id=61408

well, given the refcnt dependence and other issues, this cannot
be reproduced in Jython (and similar impl. of Python).

the issue is then that the std library itself cannot depend
on the optimisation because the std library is shared among
impls.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-02 11:09

Message:
Logged In: YES 
user_id=80475

I recommend doing both.  When and where the optimization
applies is an implementation detail (that probably won't be
replicated in Jython for example).

To do only inplace add is to miss much of the existing code
that is in need of help.  Several library modules and
benchmarks benefit greatly from doing both.  This makes
common coding styles not result in disasterous performance.  

The explanation can read something like:
"With binary additions of the form a+=b or a=a+b, CPython is
able to concatenate inplace and achieve linear running time.
 However, with chained additions like a = a + b + c, the
current implementation does not recognize the opportunity to
concatenate inplace.  Instead, a new string is constructed
at each step resulting in quadratic running time."



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-08-02 07:10

Message:
Logged In: YES 
user_id=4771

Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain.  The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will.

The rationale for only tampering with INPLACE_ADD was to make the result more predictable.  Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b.

In-place operators in Python are a dark corner of the language.  I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators.  Thus the idea of only tampering with INPLACE_ADD for the optimization here.

Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 14:42

Message:
Logged In: YES 
user_id=80475

Further timings show it is advantageous to keep BINARY_ADD
and INPLACE_ADD separate.  Revised patch attached.  Now all
benchmark tests show improvements.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 12:34

Message:
Logged In: YES 
user_id=80475

FWIW, I think the patch ought to also apply to BINARY_ADD. 
There is tons of code that writes a=a+b rather than a+=b.  
It's important that there not be a substantial performance
difference between the two; otherwise, we're introducing
another bit of arcana.

Attached is a revised patch that combines BINARY_ADD with
INPLACE_ADD for a net savings of instructions in ceval.c. 
The timings improve on all my benchmarks (PyBench for
example runs 4% faster).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 11:29

Message:
Logged In: YES 
user_id=80475

I've run with this for a couple of days and have not been
able to break it.   My benchmarks run slightly faster except
for PyBench which is 0.1% slower.  Regression tests pass
without exception.

The code itself looks fine and the approach makes sense.  It
does introduce some extra complexity and code duplication,
but the patch is still unified and comprehensible.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-25 06:18

Message:
Logged In: YES 
user_id=4771

Raymond, do you have time to review it?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-25 06:17

Message:
Logged In: YES 
user_id=4771

Here is another patch.  This one focuses on simplicity, both
implementation-wise and from the user's point of view:

1) It only makes repeated  variable += expr  faster. It
doesn't touch the '+'.
2) It doesn't mess with the internals of strings and dicts
any more.  It is just one well-documented function now.

The goal of this new patch is to be reviewable and
maintainable, to get it in the core to stop people from
being bitten by the performance of += (I just saw yet
another example yesterday).

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-06-28 07:38

Message:
Logged In: YES 
user_id=99874

Hmmm... Interesting. I kinda like it.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-28 05:41

Message:
Logged In: YES 
user_id=4771

another patch with support for STORE_DEREF (thanks Phillip for pointing it out)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-27 16:39

Message:
Logged In: YES 
user_id=4771

resubmitted as a context diff.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 17:37:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 17:37:57 2004
Subject: [Patches] [ python-Patches-1004018 ] comparison of Decimal instance
	with None fails
Message-ID: 

Patches item #1004018, was opened at 2004-08-05 09: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=1004018&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails

Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:

TypeError: You can interact Decimal only with int, long
or Decimal data types.

Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 19:46:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 19:46:35 2004
Subject: [Patches] [ python-Patches-1004088 ] big code objects (>64K) may be
	optimized incorrectly
Message-ID: 

Patches item #1004088, was opened at 2004-08-05 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=1004088&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cezary Biernacki (cezary)
Assigned to: Nobody/Anonymous (nobody)
Summary: big code objects (>64K) may be optimized incorrectly

Initial Comment:
Large functions with size of a bytecode bigger than
65535 bytes may be incorrectly optimized by
"optimize_code" in "Python/compile.c". Optimalization
happens automaticaly during loading from *.pyc and
cannot be disabled. Codes loaded directly from source
(*.py) are not optimalized and not affected by this bug.

One of task of "optimize_code" is to eliminate
"chained" jumps  (when one of jumps points directly to
unconditional jump). Problems occurs when a first jump
opcode points to JUMP_FORWARD, which target is after
64K boundary. This target adress is copied as absolute
address of the first jump modulo 2**16.

This bug can lead to different symptoms during
execution of a code. You can get an "unknown opcode"
error, but  sometimes results can be unpredicable.

This problem appears in Python 2.3 (tested) and
possibly in 2.4 (alfa). 

Attached scripts generates large functions a writes
disassebles before and after optimalization. You will
find, that some adresses after optimalization are bad. 
 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 19:53:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 19:53:49 2004
Subject: [Patches] [ python-Patches-1004088 ] big code objects (>64K) may be
	optimized incorrectly
Message-ID: 

Patches item #1004088, was opened at 2004-08-05 13:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Cezary Biernacki (cezary)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: big code objects (>64K) may be optimized incorrectly

Initial Comment:
Large functions with size of a bytecode bigger than
65535 bytes may be incorrectly optimized by
"optimize_code" in "Python/compile.c". Optimalization
happens automaticaly during loading from *.pyc and
cannot be disabled. Codes loaded directly from source
(*.py) are not optimalized and not affected by this bug.

One of task of "optimize_code" is to eliminate
"chained" jumps  (when one of jumps points directly to
unconditional jump). Problems occurs when a first jump
opcode points to JUMP_FORWARD, which target is after
64K boundary. This target adress is copied as absolute
address of the first jump modulo 2**16.

This bug can lead to different symptoms during
execution of a code. You can get an "unknown opcode"
error, but  sometimes results can be unpredicable.

This problem appears in Python 2.3 (tested) and
possibly in 2.4 (alfa). 

Attached scripts generates large functions a writes
disassebles before and after optimalization. You will
find, that some adresses after optimalization are bad. 
 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-05 13:53

Message:
Logged In: YES 
user_id=31435

Raised priority and assigned to Raymond.  I haven't verified 
the claim, but it sounds more plausible than not, and is a 
critical bug if so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 19:56:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 19:56:43 2004
Subject: [Patches] [ python-Patches-1004095 ] untested patch for compile.c
	(bug 1004088)
Message-ID: 

Patches item #1004095, was opened at 2004-08-05 19: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=1004095&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Cezary Biernacki (cezary)
Assigned to: Nobody/Anonymous (nobody)
Summary: untested patch for compile.c (bug 1004088)

Initial Comment:
An untested patch for "optimize_code" in "compile.c".
It should correct problems with optimalization of large
functions. See bug 1004088.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004095&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 19:59:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 19:59:33 2004
Subject: [Patches] [ python-Patches-1004088 ] big code objects (>64K) may be
	optimized incorrectly
Message-ID: 

Patches item #1004088, was opened at 2004-08-05 19:46
Message generated for change (Comment added) made by cezary
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Cezary Biernacki (cezary)
Assigned to: Raymond Hettinger (rhettinger)
Summary: big code objects (>64K) may be optimized incorrectly

Initial Comment:
Large functions with size of a bytecode bigger than
65535 bytes may be incorrectly optimized by
"optimize_code" in "Python/compile.c". Optimalization
happens automaticaly during loading from *.pyc and
cannot be disabled. Codes loaded directly from source
(*.py) are not optimalized and not affected by this bug.

One of task of "optimize_code" is to eliminate
"chained" jumps  (when one of jumps points directly to
unconditional jump). Problems occurs when a first jump
opcode points to JUMP_FORWARD, which target is after
64K boundary. This target adress is copied as absolute
address of the first jump modulo 2**16.

This bug can lead to different symptoms during
execution of a code. You can get an "unknown opcode"
error, but  sometimes results can be unpredicable.

This problem appears in Python 2.3 (tested) and
possibly in 2.4 (alfa). 

Attached scripts generates large functions a writes
disassebles before and after optimalization. You will
find, that some adresses after optimalization are bad. 
 


----------------------------------------------------------------------

>Comment By: Cezary Biernacki (cezary)
Date: 2004-08-05 19:59

Message:
Logged In: YES 
user_id=738

untested (sorry - no C compiler at hand) posted - see patch
"1004095"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-05 19:53

Message:
Logged In: YES 
user_id=31435

Raised priority and assigned to Raymond.  I haven't verified 
the claim, but it sounds more plausible than not, and is a 
critical bug if so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 20:12:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 20:12:49 2004
Subject: [Patches] [ python-Patches-1004095 ] untested patch for compile.c
	(bug 1004088)
Message-ID: 

Patches item #1004095, was opened at 2004-08-05 19:56
Message generated for change (Settings changed) made by cezary
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004095&group_id=5470

Category: Core (C code)
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Cezary Biernacki (cezary)
Assigned to: Nobody/Anonymous (nobody)
Summary: untested patch for compile.c (bug 1004088)

Initial Comment:
An untested patch for "optimize_code" in "compile.c".
It should correct problems with optimalization of large
functions. See bug 1004088.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004095&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 20:13:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 20:15:30 2004
Subject: [Patches] [ python-Patches-1004088 ] big code objects (>64K) may be
	optimized incorrectly
Message-ID: 

Patches item #1004088, was opened at 2004-08-05 19:46
Message generated for change (Comment added) made by cezary
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Cezary Biernacki (cezary)
Assigned to: Raymond Hettinger (rhettinger)
Summary: big code objects (>64K) may be optimized incorrectly

Initial Comment:
Large functions with size of a bytecode bigger than
65535 bytes may be incorrectly optimized by
"optimize_code" in "Python/compile.c". Optimalization
happens automaticaly during loading from *.pyc and
cannot be disabled. Codes loaded directly from source
(*.py) are not optimalized and not affected by this bug.

One of task of "optimize_code" is to eliminate
"chained" jumps  (when one of jumps points directly to
unconditional jump). Problems occurs when a first jump
opcode points to JUMP_FORWARD, which target is after
64K boundary. This target adress is copied as absolute
address of the first jump modulo 2**16.

This bug can lead to different symptoms during
execution of a code. You can get an "unknown opcode"
error, but  sometimes results can be unpredicable.

This problem appears in Python 2.3 (tested) and
possibly in 2.4 (alfa). 

Attached scripts generates large functions a writes
disassebles before and after optimalization. You will
find, that some adresses after optimalization are bad. 
 


----------------------------------------------------------------------

>Comment By: Cezary Biernacki (cezary)
Date: 2004-08-05 20:13

Message:
Logged In: YES 
user_id=738

Attached a missing patch. Untested!

----------------------------------------------------------------------

Comment By: Cezary Biernacki (cezary)
Date: 2004-08-05 19:59

Message:
Logged In: YES 
user_id=738

untested (sorry - no C compiler at hand) posted - see patch
"1004095"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-05 19:53

Message:
Logged In: YES 
user_id=31435

Raised priority and assigned to Raymond.  I haven't verified 
the claim, but it sounds more plausible than not, and is a 
critical bug if so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470
From noreply at sourceforge.net  Thu Aug  5 20:17:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug  5 20:17:50 2004
Subject: [Patches] [ python-Patches-968063 ] Add fileinput.islastline()
Message-ID: 

Patches item #968063, was opened at 2004-06-07 02:45
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Relm Arrowny (relm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add fileinput.islastline()

Initial Comment:
You can test for the first line of a file with 
fileinput.isfirstline(), but there is no corresponding 
fileinput.islastline() to test for the last line of a file.

Note that there is already an unapplied patch for this at 
request ID 776100, but it is faulty in that it only tests 
for end of buffer and not end of file.

I was not sure how to append this patch to the existing 
request, so have started a new one.  Hope this is okay.

This patch also includes documentation and test 
updates.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-05 11:17

Message:
Logged In: YES 
user_id=971153

An alternative to islastline() would be to add a single-line
look-ahead capability:

nextline()  which would return a structure containing
  next line, and its file name
(or have 2 functions
nextline()
and nextlinefile()
)

This would cover most of the OP's needs but would also
provide extra useful functionality....E.g. when processing
files which have a 

header line
[data line]*
structure

its very convenient to know in advance when section ends
while processing the last line of section not when
enountering the header line of the next section...

Another use case would be processing of files with line groups:

group1line1
group1line2
group1line3
group2line1
group2line2

(grouping could be for example on  the value of a certian
field in the line)

again it would be very useful to know when a group ends
while still processing this group


----------------------------------------------------------------------

Comment By: Dave Harrison (dharriso)
Date: 2004-07-04 04:24

Message:
Logged In: YES 
user_id=1076674

I would say that I'm -0.5 on this feature.  After looking
over the current code for fileinput.py in the cvs tree, it
looks like the current code implements an iterator model. 
Since fileinput.py uses the next() call to move along its
input, and raises StopIteration if there are no more lines
to be returned, this function would have to be polled to
find out if the final line had been reached - where a
try/except block that caught StopIteration would seem more
intuitive to me (Inkeeping with the current code).

However it might be considered that the nextfile() function
be changed to raise StopIteration after the last file had
been completed to maintain consistency between the lines and
files aspects of the class.

----------------------------------------------------------------------

Comment By: Relm Arrowny (relm)
Date: 2004-06-15 11:42

Message:
Logged In: YES 
user_id=1058331

The OP's use case was too simplified to convey
the usefulness of fileinput.islastline().  It does not
just save a couple of lines.  I am attaching a "wc" or
"word count" program to demonstrate.  Note the following
problems with the current work-around:

1. Instead of doing end-of-file processing at the end of
   a file, we must do it at the beginning of the *next*
   file.

2. Useful functions such as fileinput.filelineno() and
   fileinput.filename() now refer to the *wrong* file,
   so now we need to manually keep track of these values
   ourselves.

3. Perhaps a minor point, but this work-around only works
   at the *beginning* of the loop instead of the end.  It
   feels somewhat awkward.

4. End-of-file processing must occur both in the loop and
   once outside.  A function avoids code duplication, but
   to refer to variables in the loop, they must be passed
   into and out of the function (6 in, 2 out for the "wc"
   example... maybe keyword arguments would have helped).

5. Most important is readablility.  It's not obvious that
   `fileinput.isfirstline() and fileinput.lineno() != 1`
   means we are the end of the (previous!) file.  Using
   `fileinput.islastline()` would be much clearer.

And not that it is a reason, but Perl and Ruby solve
this with an `eof` function and `eof?` method,
respectively.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-15 05:05

Message:
Logged In: YES 
user_id=80475

I'm -0 on complicating this venerable interface.   Also, I
find it unnatural for the inside of a loop to be able to
ascertain whether it is in its final iteration.  The closest
approximation is the for-else clause which is vary rarely
used in normal python programming.  While the OP was able to
sketch a use case, it involved only saving a couple of lines
over what can be done with the existing API.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 01:00:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 01:00:21 2004
Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation
Message-ID: 

Patches item #980695, was opened at 2004-06-27 08:39
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: efficient string concatenation

Initial Comment:
A wild idea that makes repeated string concatenations efficient without changing stringobject.c.

If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1.

But with some hacks ceval.c can know that.  Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME.  So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already).  If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory).

With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely.

As a side effect, other constructions like a+b+c+d+e+f also work in-place now.

The patch would do with a lot more comments.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-05 18:00

Message:
Logged In: YES 
user_id=80475

I;ve got it from here.  Will document the coding restriction
in the style guilde and will put the quality of
implementation notes directly in the string docs.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-05 10:36

Message:
Logged In: YES 
user_id=6380

This can go in on two conditions:

1) That is clearly documented as a quality-of-implementation
issue, not a language feature

2) That it is not relied upon in the standard library (which
is shared with Jython)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-03 09:13

Message:
Logged In: YES 
user_id=6380

Not so fast, see python-dev.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-08-03 07:37

Message:
Logged In: YES 
user_id=99874

While I think CPython should get the patch, I *am* worried
about Jython (and Iron Python I suppose). In particular,
Samuele's plea to keep this out of the std library is likely
to be followed for a few months, then completely forgotten.
Perhaps we need some way to check, when running the test
suite, just how much dependence there is on this feature...
then there's at least be a way to *find* the bits where
people who didn't predate this change failed to use the
obscure ''.join() idiom that us oldtimers keep nagging about
.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2004-08-03 06:19

Message:
Logged In: YES 
user_id=61408

well, given the refcnt dependence and other issues, this cannot
be reproduced in Jython (and similar impl. of Python).

the issue is then that the std library itself cannot depend
on the optimisation because the std library is shared among
impls.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-02 10:09

Message:
Logged In: YES 
user_id=80475

I recommend doing both.  When and where the optimization
applies is an implementation detail (that probably won't be
replicated in Jython for example).

To do only inplace add is to miss much of the existing code
that is in need of help.  Several library modules and
benchmarks benefit greatly from doing both.  This makes
common coding styles not result in disasterous performance.  

The explanation can read something like:
"With binary additions of the form a+=b or a=a+b, CPython is
able to concatenate inplace and achieve linear running time.
 However, with chained additions like a = a + b + c, the
current implementation does not recognize the opportunity to
concatenate inplace.  Instead, a new string is constructed
at each step resulting in quadratic running time."



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-08-02 06:10

Message:
Logged In: YES 
user_id=4771

Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain.  The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will.

The rationale for only tampering with INPLACE_ADD was to make the result more predictable.  Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b.

In-place operators in Python are a dark corner of the language.  I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators.  Thus the idea of only tampering with INPLACE_ADD for the optimization here.

Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 13:42

Message:
Logged In: YES 
user_id=80475

Further timings show it is advantageous to keep BINARY_ADD
and INPLACE_ADD separate.  Revised patch attached.  Now all
benchmark tests show improvements.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 11:34

Message:
Logged In: YES 
user_id=80475

FWIW, I think the patch ought to also apply to BINARY_ADD. 
There is tons of code that writes a=a+b rather than a+=b.  
It's important that there not be a substantial performance
difference between the two; otherwise, we're introducing
another bit of arcana.

Attached is a revised patch that combines BINARY_ADD with
INPLACE_ADD for a net savings of instructions in ceval.c. 
The timings improve on all my benchmarks (PyBench for
example runs 4% faster).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 10:29

Message:
Logged In: YES 
user_id=80475

I've run with this for a couple of days and have not been
able to break it.   My benchmarks run slightly faster except
for PyBench which is 0.1% slower.  Regression tests pass
without exception.

The code itself looks fine and the approach makes sense.  It
does introduce some extra complexity and code duplication,
but the patch is still unified and comprehensible.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-25 05:18

Message:
Logged In: YES 
user_id=4771

Raymond, do you have time to review it?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-25 05:17

Message:
Logged In: YES 
user_id=4771

Here is another patch.  This one focuses on simplicity, both
implementation-wise and from the user's point of view:

1) It only makes repeated  variable += expr  faster. It
doesn't touch the '+'.
2) It doesn't mess with the internals of strings and dicts
any more.  It is just one well-documented function now.

The goal of this new patch is to be reviewable and
maintainable, to get it in the core to stop people from
being bitten by the performance of += (I just saw yet
another example yesterday).

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-06-28 06:38

Message:
Logged In: YES 
user_id=99874

Hmmm... Interesting. I kinda like it.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-28 04:41

Message:
Logged In: YES 
user_id=4771

another patch with support for STORE_DEREF (thanks Phillip for pointing it out)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-27 15:39

Message:
Logged In: YES 
user_id=4771

resubmitted as a context diff.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 07:16:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 07:16:59 2004
Subject: [Patches] [ python-Patches-1004018 ] comparison of Decimal instance
	with None fails
Message-ID: 

Patches item #1004018, was opened at 2004-08-05 11:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails

Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:

TypeError: You can interact Decimal only with int, long
or Decimal data types.

Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-06 01:16

Message:
Logged In: YES 
user_id=31435

Sorry, I'm opposed to this.  Silently delivering a result when 
comparing to None has few intelligible use cases, but does 
hide errors quite effectively.  For this reason, it's generally 
true that the newer types in Python refuse non-equality 
comparisons with None (or with any other senselessly 
incompatible type).  For example,

>>> from datetime import date
>>> date.today() < None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't compare datetime.date to NoneType

>>> set([1, 2]) > None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can only compare to a set
>>>

The new collections.deque type is an oddball in this respect, 
and should probably be "fixed":

>>> import collections
>>> collections.deque() > None
True
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 06:45:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 08:21:19 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 08:39:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 08:39:44 2004
Subject: [Patches] [ python-Patches-1003693 ] Fix for 1002475 (Feedparser
	not handling \r\n correctly)
Message-ID: 

Patches item #1003693, was opened at 2004-08-05 03:27
Message generated for change (Comment added) made by sjoerd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Fix for 1002475 (Feedparser not handling \r\n correctly)

Initial Comment:
Python 2.4a1/Anon CVS of 5 Aug 2004.  WinXP SP1, not
that that matters.

This is a patch to fix bug:

[ 1002475 ] email message parser doesn't handle \r\n
correctly
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475

Basically, FeedParser does a rstrip() on the last
header value, but not any of the others.  Given that
RFC822 wants the headers to end with \r\n, it's likely
that most will, and this means that all the headers
except for the last end with \r.  This one line patch
just does the extra rstrip.

Note that you might want to implement the fix yourself
- it doesn't fit on a line, and so it's wrapped in an
ugly way - maybe you can think of something prettier :)
 This does fix the problem, though (here, at least,
using the test case outlined in the bug report).

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-08-06 08:39

Message:
Logged In: YES 
user_id=43607

I've only tried the patch, not the test, but it seems to
work well.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 04:09

Message:
Logged In: YES 
user_id=552329

Second test was in the wrong place, so moving.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 03:48

Message:
Logged In: YES 
user_id=552329

Also attached is a patch for test_email.py.  This adds two
new tests (which fail before the FeedParser.py patch, and
pass afterwards).

The first tests that the \r\n characters are correctly removed.
The second is a copy of an existing test to check
continuations with whitespace, but checks if it works with
the continuation as the last header.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-05 03:46

Message:
Logged In: YES 
user_id=552329

Attaching new patch, because that one breaks one of the
tests.  The rstrip() needs to be rstrip('\r\n') or it strips
other whitespace that isn't allowed there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 09:10:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 09:10:48 2004
Subject: [Patches] [ python-Patches-1003700 ] add socketpair function to
	socket module
Message-ID: 

Patches item #1003700, was opened at 2004-08-05 04:09
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Dave Cole (davecole)
>Assigned to: Dave Cole (davecole)
Summary: add socketpair function to socket module

Initial Comment:
Adds a socketpair() function to the socketmodule.c.  
The function returns two socket objects.

Contains some simple unit tests that check the return
value from socketpair is actually two functioning sockets.

Outstanding question is whether the family, type, proto
arguments should be kwargs as per socket() function, or
positional as per fromfd() function.  If kwargs, then
it is arguable that the fromfd() arguments should be
changed (in another patch).


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 09:10

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply. Make sure to
- add \versionadded{2.4} into the documentation
- add an entry to Misc/NEWS

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 15:46:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 15:46:39 2004
Subject: [Patches] [ python-Patches-1004018 ] comparison of Decimal instance
	with None fails
Message-ID: 

Patches item #1004018, was opened at 2004-08-05 09:37
Message generated for change (Comment added) made by atuining
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails

Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:

TypeError: You can interact Decimal only with int, long
or Decimal data types.

Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.

----------------------------------------------------------------------

>Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 07:46

Message:
Logged In: YES 
user_id=619560

Ah, very interesting. I hadn't tried datetime data yet and
that one will also be an issue for us. Let  me give you a
little background so you know why I am suggesting this. We
are acquiring data from a database where floating point
numbers are returned as decimal instances and date as
datetime instances. Some of this data may be null which in
DB API parlance means a None instance. Its quite annoying to
have a list of data values, some of which are null and have
a TypeError exception raised. I'm not sure how familiar you
are with the DB API and databases in general but this
behavior makes such types unusable -- which is unfortunate.
We will have to subclass or write our own "Value" class that
has the behavior we want. Do you have any further comments
about the concept of "null" with respect to databases? Or do
your existing comments still stand?

The other question I would leave you with is: comparing with
an empty set is quite possible, but how about an "empty"
decimal or "empty" datetime instance?

Thanks for the response thus far -- even if it wasn't what I
wanted. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-05 23:16

Message:
Logged In: YES 
user_id=31435

Sorry, I'm opposed to this.  Silently delivering a result when 
comparing to None has few intelligible use cases, but does 
hide errors quite effectively.  For this reason, it's generally 
true that the newer types in Python refuse non-equality 
comparisons with None (or with any other senselessly 
incompatible type).  For example,

>>> from datetime import date
>>> date.today() < None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't compare datetime.date to NoneType

>>> set([1, 2]) > None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can only compare to a set
>>>

The new collections.deque type is an oddball in this respect, 
and should probably be "fixed":

>>> import collections
>>> collections.deque() > None
True
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 18:06:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 18:06:38 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 17:06
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=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 18:53:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 18:53:54 2004
Subject: [Patches] [ python-Patches-1004018 ] comparison of Decimal instance
	with None fails
Message-ID: 

Patches item #1004018, was opened at 2004-08-05 11:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails

Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:

TypeError: You can interact Decimal only with int, long
or Decimal data types.

Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-06 12:53

Message:
Logged In: YES 
user_id=31435

Sorry, this isn't clear:

> Its quite annoying to have a list of data values, some of
> which are null and have a TypeError exception raised.

Putting None in a list simply does not raise TypeError.  What, 
exactly, do you do that *does* raise TypeError?  The 
datetime and set types *do* allow mixed-type equality 
comparison, so there's no problem mixing None with instances 
of those types as dict keys, or for operations like "thing in 
list" or "list.remove(thing)", or for anything else that only asks 
about equality.  "datetime.date == x" is False if x has any 
incompatible type, and "datetime.date != x" is True.

An "empty decimal" doesn't make sense to me, and would be 
an extension to the IBM standard that Decimal is trying to 
implement faithfully.  A world of semantics would need to be 
defined for it (what exactly does it do in all Decimal 
operations, under all option settings), and that's a big job.

As far as general database "missing value" thingies go, 
Python's None doesn't reflect their natural semantics in many 
ways.  For example, 3+None raises an exception too -- None 
almost never "propagates silently" in Python.

----------------------------------------------------------------------

Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 09:46

Message:
Logged In: YES 
user_id=619560

Ah, very interesting. I hadn't tried datetime data yet and
that one will also be an issue for us. Let  me give you a
little background so you know why I am suggesting this. We
are acquiring data from a database where floating point
numbers are returned as decimal instances and date as
datetime instances. Some of this data may be null which in
DB API parlance means a None instance. Its quite annoying to
have a list of data values, some of which are null and have
a TypeError exception raised. I'm not sure how familiar you
are with the DB API and databases in general but this
behavior makes such types unusable -- which is unfortunate.
We will have to subclass or write our own "Value" class that
has the behavior we want. Do you have any further comments
about the concept of "null" with respect to databases? Or do
your existing comments still stand?

The other question I would leave you with is: comparing with
an empty set is quite possible, but how about an "empty"
decimal or "empty" datetime instance?

Thanks for the response thus far -- even if it wasn't what I
wanted. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-06 01:16

Message:
Logged In: YES 
user_id=31435

Sorry, I'm opposed to this.  Silently delivering a result when 
comparing to None has few intelligible use cases, but does 
hide errors quite effectively.  For this reason, it's generally 
true that the newer types in Python refuse non-equality 
comparisons with None (or with any other senselessly 
incompatible type).  For example,

>>> from datetime import date
>>> date.today() < None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't compare datetime.date to NoneType

>>> set([1, 2]) > None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can only compare to a set
>>>

The new collections.deque type is an oddball in this respect, 
and should probably be "fixed":

>>> import collections
>>> collections.deque() > None
True
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 19:06:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 19:06:11 2004
Subject: [Patches] [ python-Patches-1004018 ] comparison of Decimal instance
	with None fails
Message-ID: 

Patches item #1004018, was opened at 2004-08-05 09:37
Message generated for change (Comment added) made by atuining
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails

Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:

TypeError: You can interact Decimal only with int, long
or Decimal data types.

Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.

----------------------------------------------------------------------

>Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 11:06

Message:
Logged In: YES 
user_id=619560

Its list.sort() that causes the issue. Clearly the concept
of "null" is not really present in Python (as it isn't in
many other languages) and to try to shoehorn it in in just a
few places would be unwise at best. Please consider my
request to patch decimal.py revoked. :-)

Just as a side note. As for "empty" decimal and the like --
I wasn't actually suggesting such a thing. In PL/SQL from
Oracle (and other languages) there is a null indicator
associated with each variable. Thus, you can have a string
that is null, a date that is null, a number that is null,
etc. Unfortunately, this doesn't propagate to other
languages and environments -- I am familiar with some that
do it this way and some that don't and the the ones that do
don't do it exactly the same way, either.... :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-06 10:53

Message:
Logged In: YES 
user_id=31435

Sorry, this isn't clear:

> Its quite annoying to have a list of data values, some of
> which are null and have a TypeError exception raised.

Putting None in a list simply does not raise TypeError.  What, 
exactly, do you do that *does* raise TypeError?  The 
datetime and set types *do* allow mixed-type equality 
comparison, so there's no problem mixing None with instances 
of those types as dict keys, or for operations like "thing in 
list" or "list.remove(thing)", or for anything else that only asks 
about equality.  "datetime.date == x" is False if x has any 
incompatible type, and "datetime.date != x" is True.

An "empty decimal" doesn't make sense to me, and would be 
an extension to the IBM standard that Decimal is trying to 
implement faithfully.  A world of semantics would need to be 
defined for it (what exactly does it do in all Decimal 
operations, under all option settings), and that's a big job.

As far as general database "missing value" thingies go, 
Python's None doesn't reflect their natural semantics in many 
ways.  For example, 3+None raises an exception too -- None 
almost never "propagates silently" in Python.

----------------------------------------------------------------------

Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 07:46

Message:
Logged In: YES 
user_id=619560

Ah, very interesting. I hadn't tried datetime data yet and
that one will also be an issue for us. Let  me give you a
little background so you know why I am suggesting this. We
are acquiring data from a database where floating point
numbers are returned as decimal instances and date as
datetime instances. Some of this data may be null which in
DB API parlance means a None instance. Its quite annoying to
have a list of data values, some of which are null and have
a TypeError exception raised. I'm not sure how familiar you
are with the DB API and databases in general but this
behavior makes such types unusable -- which is unfortunate.
We will have to subclass or write our own "Value" class that
has the behavior we want. Do you have any further comments
about the concept of "null" with respect to databases? Or do
your existing comments still stand?

The other question I would leave you with is: comparing with
an empty set is quite possible, but how about an "empty"
decimal or "empty" datetime instance?

Thanks for the response thus far -- even if it wasn't what I
wanted. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-05 23:16

Message:
Logged In: YES 
user_id=31435

Sorry, I'm opposed to this.  Silently delivering a result when 
comparing to None has few intelligible use cases, but does 
hide errors quite effectively.  For this reason, it's generally 
true that the newer types in Python refuse non-equality 
comparisons with None (or with any other senselessly 
incompatible type).  For example,

>>> from datetime import date
>>> date.today() < None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't compare datetime.date to NoneType

>>> set([1, 2]) > None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can only compare to a set
>>>

The new collections.deque type is an oddball in this respect, 
and should probably be "fixed":

>>> import collections
>>> collections.deque() > None
True
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 20:18:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 20:18:21 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 11:06
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 13:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 20:47:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 20:47:47 2004
Subject: [Patches] [ python-Patches-980695 ] efficient string concatenation
Message-ID: 

Patches item #980695, was opened at 2004-06-27 08:39
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: efficient string concatenation

Initial Comment:
A wild idea that makes repeated string concatenations efficient without changing stringobject.c.

If we assume we don't want to change the representation of strings, then the problem is that string_concat(v,w) doesn't know if v will soon released, so it cannot resize it in-place even if the refcnt is 1.

But with some hacks ceval.c can know that.  Statements like s=s+expr or s+=expr both compile to a BINARY_ADD or INPLACE_ADD followed by a STORE_FAST or STORE_NAME.  So in the attached patch ceval.c special-cases addition of two strings (in the same way as it special-cases addition of two integers already).  If moreover the addition is followed by a STORE that is about to overwrite the addition's left argument, and if the refcnt is right, then the left argument can be resized in-place (plus some obscure magic to ensure that everything is still valid even if resize moves the string in memory).

With Python's good memory manager, repeated resizes even without manual over-allocation perform nicely.

As a side effect, other constructions like a+b+c+d+e+f also work in-place now.

The patch would do with a lot more comments.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-06 13:47

Message:
Logged In: YES 
user_id=80475

Applied as:

Python/ceval.c 2.413
Doc/lib/libstdtypes.tex 1.160
nondist/peps/pep-0008.txt 1.25

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-05 18:00

Message:
Logged In: YES 
user_id=80475

I;ve got it from here.  Will document the coding restriction
in the style guilde and will put the quality of
implementation notes directly in the string docs.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-05 10:36

Message:
Logged In: YES 
user_id=6380

This can go in on two conditions:

1) That is clearly documented as a quality-of-implementation
issue, not a language feature

2) That it is not relied upon in the standard library (which
is shared with Jython)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-03 09:13

Message:
Logged In: YES 
user_id=6380

Not so fast, see python-dev.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-08-03 07:37

Message:
Logged In: YES 
user_id=99874

While I think CPython should get the patch, I *am* worried
about Jython (and Iron Python I suppose). In particular,
Samuele's plea to keep this out of the std library is likely
to be followed for a few months, then completely forgotten.
Perhaps we need some way to check, when running the test
suite, just how much dependence there is on this feature...
then there's at least be a way to *find* the bits where
people who didn't predate this change failed to use the
obscure ''.join() idiom that us oldtimers keep nagging about
.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2004-08-03 06:19

Message:
Logged In: YES 
user_id=61408

well, given the refcnt dependence and other issues, this cannot
be reproduced in Jython (and similar impl. of Python).

the issue is then that the std library itself cannot depend
on the optimisation because the std library is shared among
impls.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-02 10:09

Message:
Logged In: YES 
user_id=80475

I recommend doing both.  When and where the optimization
applies is an implementation detail (that probably won't be
replicated in Jython for example).

To do only inplace add is to miss much of the existing code
that is in need of help.  Several library modules and
benchmarks benefit greatly from doing both.  This makes
common coding styles not result in disasterous performance.  

The explanation can read something like:
"With binary additions of the form a+=b or a=a+b, CPython is
able to concatenate inplace and achieve linear running time.
 However, with chained additions like a = a + b + c, the
current implementation does not recognize the opportunity to
concatenate inplace.  Instead, a new string is constructed
at each step resulting in quadratic running time."



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-08-02 06:10

Message:
Logged In: YES 
user_id=4771

Optimizing BINARY_ADD was what I did in the first patch too, but it has the drawback of being harder to explain.  The main trouble I see is that a=a+b+c will NOT be accelerated, while a=a+b or a+=b+c will.

The rationale for only tampering with INPLACE_ADD was to make the result more predictable.  Moreover the behavior would be superficially similar to what occurs with lists with a=a+b vs a+=b.

In-place operators in Python are a dark corner of the language.  I think it is OK for people to think about it as a possibly optimized (in-place-modifying) version of the standard operators.  Thus the idea of only tampering with INPLACE_ADD for the optimization here.

Well, maybe you can find a convincingly clear explanation of why a=a+b works but a=a+b+c doesn't.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 13:42

Message:
Logged In: YES 
user_id=80475

Further timings show it is advantageous to keep BINARY_ADD
and INPLACE_ADD separate.  Revised patch attached.  Now all
benchmark tests show improvements.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 11:34

Message:
Logged In: YES 
user_id=80475

FWIW, I think the patch ought to also apply to BINARY_ADD. 
There is tons of code that writes a=a+b rather than a+=b.  
It's important that there not be a substantial performance
difference between the two; otherwise, we're introducing
another bit of arcana.

Attached is a revised patch that combines BINARY_ADD with
INPLACE_ADD for a net savings of instructions in ceval.c. 
The timings improve on all my benchmarks (PyBench for
example runs 4% faster).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-01 10:29

Message:
Logged In: YES 
user_id=80475

I've run with this for a couple of days and have not been
able to break it.   My benchmarks run slightly faster except
for PyBench which is 0.1% slower.  Regression tests pass
without exception.

The code itself looks fine and the approach makes sense.  It
does introduce some extra complexity and code duplication,
but the patch is still unified and comprehensible.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-25 05:18

Message:
Logged In: YES 
user_id=4771

Raymond, do you have time to review it?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-25 05:17

Message:
Logged In: YES 
user_id=4771

Here is another patch.  This one focuses on simplicity, both
implementation-wise and from the user's point of view:

1) It only makes repeated  variable += expr  faster. It
doesn't touch the '+'.
2) It doesn't mess with the internals of strings and dicts
any more.  It is just one well-documented function now.

The goal of this new patch is to be reviewable and
maintainable, to get it in the core to stop people from
being bitten by the performance of += (I just saw yet
another example yesterday).

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-06-28 06:38

Message:
Logged In: YES 
user_id=99874

Hmmm... Interesting. I kinda like it.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-28 04:41

Message:
Logged In: YES 
user_id=4771

another patch with support for STORE_DEREF (thanks Phillip for pointing it out)

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-27 15:39

Message:
Logged In: YES 
user_id=4771

resubmitted as a context diff.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980695&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 21:47:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 21:47:29 2004
Subject: [Patches] [ python-Patches-1004088 ] big code objects (>64K) may be
	optimized incorrectly
Message-ID: 

Patches item #1004088, was opened at 2004-08-05 12:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
>Priority: 5
Submitted By: Cezary Biernacki (cezary)
Assigned to: Raymond Hettinger (rhettinger)
Summary: big code objects (>64K) may be optimized incorrectly

Initial Comment:
Large functions with size of a bytecode bigger than
65535 bytes may be incorrectly optimized by
"optimize_code" in "Python/compile.c". Optimalization
happens automaticaly during loading from *.pyc and
cannot be disabled. Codes loaded directly from source
(*.py) are not optimalized and not affected by this bug.

One of task of "optimize_code" is to eliminate
"chained" jumps  (when one of jumps points directly to
unconditional jump). Problems occurs when a first jump
opcode points to JUMP_FORWARD, which target is after
64K boundary. This target adress is copied as absolute
address of the first jump modulo 2**16.

This bug can lead to different symptoms during
execution of a code. You can get an "unknown opcode"
error, but  sometimes results can be unpredicable.

This problem appears in Python 2.3 (tested) and
possibly in 2.4 (alfa). 

Attached scripts generates large functions a writes
disassebles before and after optimalization. You will
find, that some adresses after optimalization are bad. 
 


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-06 14:47

Message:
Logged In: YES 
user_id=80475

Thanks for the report and patch.
Fixed in Python/compile.c 2.314
Will backport to Py2.3


----------------------------------------------------------------------

Comment By: Cezary Biernacki (cezary)
Date: 2004-08-05 13:13

Message:
Logged In: YES 
user_id=738

Attached a missing patch. Untested!

----------------------------------------------------------------------

Comment By: Cezary Biernacki (cezary)
Date: 2004-08-05 12:59

Message:
Logged In: YES 
user_id=738

untested (sorry - no C compiler at hand) posted - see patch
"1004095"

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-05 12:53

Message:
Logged In: YES 
user_id=31435

Raised priority and assigned to Raymond.  I haven't verified 
the claim, but it sounds more plausible than not, and is a 
critical bug if so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004088&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 21:53:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 21:53:30 2004
Subject: [Patches] [ python-Patches-1004018 ] comparison of Decimal instance
	with None fails
Message-ID: 

Patches item #1004018, was opened at 2004-08-05 10:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Nobody/Anonymous (nobody)
Summary: comparison of Decimal instance with None fails

Initial Comment:
attempting to perform a comparison of None with a
Decimal instance yields a type error:

TypeError: You can interact Decimal only with int, long
or Decimal data types.

Since all other types (that I am aware of anyway)
compare higher than None, it would make sense that the
new Decimal type would compare higher as well. Attached
is a patch that does just that. Comments welcome.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-06 14:53

Message:
Logged In: YES 
user_id=80475

The new key= argument for list.sort in Py2.4 may help assign
a temporary value to fields containing None:

   mydata.sort(key=lambda v:  v is None and Decimal('Inf') or v)



----------------------------------------------------------------------

Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 12:06

Message:
Logged In: YES 
user_id=619560

Its list.sort() that causes the issue. Clearly the concept
of "null" is not really present in Python (as it isn't in
many other languages) and to try to shoehorn it in in just a
few places would be unwise at best. Please consider my
request to patch decimal.py revoked. :-)

Just as a side note. As for "empty" decimal and the like --
I wasn't actually suggesting such a thing. In PL/SQL from
Oracle (and other languages) there is a null indicator
associated with each variable. Thus, you can have a string
that is null, a date that is null, a number that is null,
etc. Unfortunately, this doesn't propagate to other
languages and environments -- I am familiar with some that
do it this way and some that don't and the the ones that do
don't do it exactly the same way, either.... :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-06 11:53

Message:
Logged In: YES 
user_id=31435

Sorry, this isn't clear:

> Its quite annoying to have a list of data values, some of
> which are null and have a TypeError exception raised.

Putting None in a list simply does not raise TypeError.  What, 
exactly, do you do that *does* raise TypeError?  The 
datetime and set types *do* allow mixed-type equality 
comparison, so there's no problem mixing None with instances 
of those types as dict keys, or for operations like "thing in 
list" or "list.remove(thing)", or for anything else that only asks 
about equality.  "datetime.date == x" is False if x has any 
incompatible type, and "datetime.date != x" is True.

An "empty decimal" doesn't make sense to me, and would be 
an extension to the IBM standard that Decimal is trying to 
implement faithfully.  A world of semantics would need to be 
defined for it (what exactly does it do in all Decimal 
operations, under all option settings), and that's a big job.

As far as general database "missing value" thingies go, 
Python's None doesn't reflect their natural semantics in many 
ways.  For example, 3+None raises an exception too -- None 
almost never "propagates silently" in Python.

----------------------------------------------------------------------

Comment By: Anthony Tuininga (atuining)
Date: 2004-08-06 08:46

Message:
Logged In: YES 
user_id=619560

Ah, very interesting. I hadn't tried datetime data yet and
that one will also be an issue for us. Let  me give you a
little background so you know why I am suggesting this. We
are acquiring data from a database where floating point
numbers are returned as decimal instances and date as
datetime instances. Some of this data may be null which in
DB API parlance means a None instance. Its quite annoying to
have a list of data values, some of which are null and have
a TypeError exception raised. I'm not sure how familiar you
are with the DB API and databases in general but this
behavior makes such types unusable -- which is unfortunate.
We will have to subclass or write our own "Value" class that
has the behavior we want. Do you have any further comments
about the concept of "null" with respect to databases? Or do
your existing comments still stand?

The other question I would leave you with is: comparing with
an empty set is quite possible, but how about an "empty"
decimal or "empty" datetime instance?

Thanks for the response thus far -- even if it wasn't what I
wanted. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-06 00:16

Message:
Logged In: YES 
user_id=31435

Sorry, I'm opposed to this.  Silently delivering a result when 
comparing to None has few intelligible use cases, but does 
hide errors quite effectively.  For this reason, it's generally 
true that the newer types in Python refuse non-equality 
comparisons with None (or with any other senselessly 
incompatible type).  For example,

>>> from datetime import date
>>> date.today() < None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't compare datetime.date to NoneType

>>> set([1, 2]) > None
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can only compare to a set
>>>

The new collections.deque type is an oddball in this respect, 
and should probably be "fixed":

>>> import collections
>>> collections.deque() > None
True
>>>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004018&group_id=5470
From noreply at sourceforge.net  Fri Aug  6 22:44:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug  6 22:44:24 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 18:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 22:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 20:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 07:06:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 07:06:30 2004
Subject: [Patches] [ python-Patches-1005008 ] curses.wrapper should also
	forward keyword args
Message-ID: 

Patches item #1005008, was opened at 2004-08-07 00:06
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=1005008&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Nichols (rob_nichols)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses.wrapper should also forward keyword args

Initial Comment:
curses.wrapper currently accepts and forwards extra
positional arguments.  Seems it should do the same for
extra keyword arguments.  This patch adds that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005008&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 12:49:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 12:50:01 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-07 02:06
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-07 20:49

Message:
Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-07 06:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-07 04:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 15:10:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 15:10:30 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 17:06
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 14:10

Message:
Logged In: YES 
user_id=6656

> Should we require that the new function name is a valid
> identifier?

We could, but I don't really see it being worth the effort
(no attempt is made to ensure that a type's __name__ is a
valid identifier today).

> If not, is an empty string an acceptable function name?

Don't see why not.

> Also, are string subtypes allowed?

Again, don't see why not.

> There should be \versionchanged in the documentation.

Yes.  In fact the documentation of function attributes could
do with being rewritten entirely....

I'll note that all the possibilities you mention are
possiblities today, via new.function.  I'm really not
changing very much.

Agree with Anthony that we don't want to allow unicode.

(While we're at it, I see that func_repr takes into account
that func_name might be Py_None, but I don't think this is
actually possible.  Any ideas?).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-07 11:49

Message:
Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 21:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 19:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 15:40:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 15:40:23 2004
Subject: [Patches] [ python-Patches-1005123 ] test_curses fails on MacOS X
	10.3
Message-ID: 

Patches item #1005123, was opened at 2004-08-07 15:40
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=1005123&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_curses fails on MacOS X 10.3

Initial Comment:
test_curses fails on MacOS X 10.3.

I'm seeing two failures:

The call to curses.curs_set at line 143 (in module_funcs) fails (that 
is raises curses.error), which the test doesn't expect.  

The test for curses.use_default_colors() (also in module_funcs) 
also fails. curses.has_colors() is False, which probably explains 
why use_default_colors fails.

The attached patch adds a try block around the call to 
curses.curs_set and reindents the test for 
curses.use_default_colors().

WARNING: I've never used curses. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 15:41:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 15:41:56 2004
Subject: [Patches] [ python-Patches-1005123 ] test_curses fails on MacOS X
	10.3
Message-ID: 

Patches item #1005123, was opened at 2004-08-07 15:40
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470

>Category: Tests
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_curses fails on MacOS X 10.3

Initial Comment:
test_curses fails on MacOS X 10.3.

I'm seeing two failures:

The call to curses.curs_set at line 143 (in module_funcs) fails (that 
is raises curses.error), which the test doesn't expect.  

The test for curses.use_default_colors() (also in module_funcs) 
also fails. curses.has_colors() is False, which probably explains 
why use_default_colors fails.

The attached patch adds a try block around the call to 
curses.curs_set and reindents the test for 
curses.use_default_colors().

WARNING: I've never used curses. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 15:43:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 15:43:25 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 18:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-07 15:43

Message:
Logged In: YES 
user_id=21627

These decisions are all fine with me.

As for anonymous functions: It appears that compile.c
2.36/funcobject.c 2.7 introduce the notion of anonymous code
objects (30-Nov-93). compile.c 2.48 (18-Jul-95) takes this
option out again, along with introducing keyword arguments.
So it is probably safe to drop the support for anonymous
functions.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 15:10

Message:
Logged In: YES 
user_id=6656

> Should we require that the new function name is a valid
> identifier?

We could, but I don't really see it being worth the effort
(no attempt is made to ensure that a type's __name__ is a
valid identifier today).

> If not, is an empty string an acceptable function name?

Don't see why not.

> Also, are string subtypes allowed?

Again, don't see why not.

> There should be \versionchanged in the documentation.

Yes.  In fact the documentation of function attributes could
do with being rewritten entirely....

I'll note that all the possibilities you mention are
possiblities today, via new.function.  I'm really not
changing very much.

Agree with Anthony that we don't want to allow unicode.

(While we're at it, I see that func_repr takes into account
that func_name might be Py_None, but I don't think this is
actually possible.  Any ideas?).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-07 12:49

Message:
Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 22:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 20:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 15:58:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 15:58:26 2004
Subject: [Patches] [ python-Patches-1005123 ] test_curses fails on MacOS X
	10.3
Message-ID: 

Patches item #1005123, was opened at 2004-08-07 15:40
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_curses fails on MacOS X 10.3

Initial Comment:
test_curses fails on MacOS X 10.3.

I'm seeing two failures:

The call to curses.curs_set at line 143 (in module_funcs) fails (that 
is raises curses.error), which the test doesn't expect.  

The test for curses.use_default_colors() (also in module_funcs) 
also fails. curses.has_colors() is False, which probably explains 
why use_default_colors fails.

The attached patch adds a try block around the call to 
curses.curs_set and reindents the test for 
curses.use_default_colors().

WARNING: I've never used curses. 

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 15:58

Message:
Logged In: YES 
user_id=580910

I've guarded the call to curs_set by tigetstr("cnorm"), based on a 
suggestion by mwh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 16:27:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 16:27:35 2004
Subject: [Patches] [ python-Patches-976869 ] Stripping script extensions
	with distutils
Message-ID: 

Patches item #976869, was opened at 2004-06-21 11:40
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976869&group_id=5470

Category: Distutils and setup.py
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Stripping script extensions with distutils

Initial Comment:
The attached patch adds the ability to distutils to
have extensions stripped from scripts when they are
"built".  This adds an option, --strip-extensions, to
the build_scripts command which defaults to false; the
option is only honored on systems for which os.name ==
"posix" and sys.platform != "darwin".

While I generally like the idea of such a feature,
there are some open issues regarding this:

1.  To support legacy applications which install
scripts with extensions but which want the new option
to apply to more recently added scripts by default,
there needs to be a way to specify this on a per-script
basis.  I've not thought about how to do this yet, but
I'd generally prefer to have this option set in a
setup.cfg file included in a distribution.

2. Mac OS X appearantly still has some issues with the
differences between GUI and non-GUI applications, and
the extension on a script is being used to help
determine the context in which scripts should be run.

As a result, I think this feature should not be
accepted in this form, but warrants further thought to
make it easier to create a declarative way to specify
what the proper treatment of individual scripts should be.

I'm posting the patch so others can review it, and to
provide a record of these issues.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-07 09:27

Message:
Logged In: YES 
user_id=2772

I've wanted another related feature:  I wrote an image
viewer program using pygame.  It works nicely on windows and
unix.

In the source tree, I named the script with a .py extension,
but when installing on unix I want no extension, and when
installing on Windows I want a .pyw extension.

Whatever scheme is developed for naming installed scripts,
it should also allow renaming to .pyw on Windows.

My own setup.py replaces build_scripts so that the scripts=
parameter to setup is a mapping {installed_name : source
name}, and provides two functions WINDOWED(s) and
TERMINAL(s) to return s plus the appropriate extension, if any.

Like Fred, I don't think this is an ultimate solution.

My setup.py can be viewed:
http://unpy.net/cgi-bin/viewcvs.cgi/xvp/setup.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=976869&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 16:29:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 16:29:34 2004
Subject: [Patches] [ python-Patches-981773 ] crach link c++ extension by
	mingw
Message-ID: 

Patches item #981773, was opened at 2004-06-29 01:42
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandr Zamaraev (shura_zam)
Assigned to: Nobody/Anonymous (nobody)
Summary: crach link c++ extension by mingw

Initial Comment:
if cource of exttension module writen in C++
setup break and say:

cc -mno-cygwin -shared -s build\temp.win32-2.3
\Release\dybaseapi.o 
build\temp.win32-2.3\Release\..\src\btree.o 
build\temp.win32-2.3\Release\..\src\database.o 
build\temp.win32-2.3\Release\..\src\dybase.o 
build\temp.win32-2.3\Release\..\src\file.o 
build\temp.win32-2.3\Release\..\src\pagepool.o 
build\temp.win32-2.3\Release\dybaseapi.def 
-LC:\Lang\Python23\libs -LC:\Lang\Python23\PCBuild 
-lpython23 -o build\lib.win32-2.3\dybaseapi.pyd
error: command 'cc' failed: No such file or directory

I patch cygwinccompiler.py for resolve:

*** C:\Lang\Python23\work\Python-2.3.4
\Lib\distutils\cygwinccompiler.py	Mon Apr 14 
19:51:26 2003
--- C:\Lang\Python23\work\cygwinccompiler2.py
	Tue Jun 29 13:00:23 2004
***************
*** 108,113 ****
--- 108,114 ----
          # XXX optimization, warnings etc. should be 
customizable.
          self.set_executables(compiler='gcc -mcygwin -O -
Wall',
                               compiler_so='gcc -mcygwin -
mdll -O -Wall',
+                              compiler_cxx='g++ -mcygwin -O -
Wall',
                               linker_exe='gcc -mcygwin',
                               linker_so=('%s -mcygwin %s' %
                                          (self.linker_dll, 
shared_option)))
***************
*** 295,300 ****
--- 296,302 ----
  
          self.set_executables(compiler='gcc -mno-
cygwin -O -Wall',
                               compiler_so='gcc -mno-cygwin -
mdll -O -Wall',
+                              compiler_cxx='g++ -mno-cygwin -
O -Wall',
                               linker_exe='gcc -mno-cygwin',
                               linker_so='%s -mno-cygwin %s %
s'
                                          % (self.linker_dll, 
shared_option,


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-07 09:29

Message:
Logged In: YES 
user_id=2772

Please attach your diff, rather than pasting it into the
text box.  The diff is hopelessly mangled, and cannot be
applied for testing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:00:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:00:38 2004
Subject: [Patches] [ python-Patches-748126 ] Nails down the semantics of
	dict setitem
Message-ID: 

Patches item #748126, was opened at 2003-06-03 07:57
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Nails down the semantics of dict setitem

Initial Comment:
You could consider accomplishing the same thing in the 
footnotes area, but I didn't see any reason to make the 
reader jump around for this info.

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-08-07 11:00

Message:
Logged In: YES 
user_id=99874

I asked about this on python-dev. Turns out that the
behavior is the same in CPython and Jython (at least), but
that it is officially undefined in the language (ie, if
someone finds a more efficient way to implement a dict which
happens to alter what happens when assigning to existing
keys, then it might change). Therefore, I think it should
NOT be documented. It's rare that people would create
objects that compare equal and yet care which one is used,
and anyone doing so should know what they're doing well
enough to test it out.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2003-07-03 22:42

Message:
Logged In: YES 
user_id=52572

I think I originally tried to attach a patch which SF dropped 
due to one of its usual bugs.   I think the question was 
whether d[k] = y would unconditionally set the identity of the 
key object in d to k, or whether any previous equal key in 
that "slot" would be preserved.  It's the latter, and the 
current docs don't say which one it is.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-07-03 21:06

Message:
Logged In: YES 
user_id=3066

This report is very vague.  What part of the documentation
are you referring to, and how do you think it should be changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:09:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:09:52 2004
Subject: [Patches] [ python-Patches-829073 ] ref. manual talks of 'sequence'
	instead of 'iterable'
Message-ID: 

Patches item #829073, was opened at 2003-10-23 13:51
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=829073&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref. manual talks of 'sequence' instead of 'iterable'

Initial Comment:
The language reference of Python 2.3 and the one of
Python 2.4a0 says the expression_list in a for
statement should yield a sequence. However, it may
yield any iterable, so this is not really true. It is
correct earlier in the text, since it does say "or
other iterable object" earlier. This patch changes the
mention of "sequence" to "iterable" in two more
occurences of the language reference of the for statement.

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-08-07 11:09

Message:
Logged In: YES 
user_id=99874

I'm in favor of the change. Brett's point is valid (that it
*also* accepts an object that defines __getitem__ but isn't
a valid iterable). But (these days) the key thing is that it
should be an iterable.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-10-23 20:44

Message:
Logged In: YES 
user_id=357491

This is slightly touchy wording.  It does accept an object that 
defines __getitem__ and not __iter__, and vice-versa.  And since 
iterables can be thought of as sequences it still basically works.

But I have no issue moving over to "iterable", personally.  I am 
going to let someone else weigh in on this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=829073&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:22:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:22:14 2004
Subject: [Patches] [ python-Patches-1005008 ] curses.wrapper should also
	forward keyword args
Message-ID: 

Patches item #1005008, was opened at 2004-08-07 06:06
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005008&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Rob Nichols (rob_nichols)
>Assigned to: Michael Hudson (mwh)
Summary: curses.wrapper should also forward keyword args

Initial Comment:
curses.wrapper currently accepts and forwards extra
positional arguments.  Seems it should do the same for
extra keyword arguments.  This patch adds that.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 16:22

Message:
Logged In: YES 
user_id=6656

Partially applied in Lib/curses/wrapper.py revision 1.8 and then 
properly in 1.9 (oops).

I also rewrote it to use finally.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005008&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:25:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:25:37 2004
Subject: [Patches] [ python-Patches-931938 ] prefix and exec_prefix as root
	dir bug
Message-ID: 

Patches item #931938, was opened at 2004-04-08 21:04
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931938&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Goertzen (goertzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: prefix and exec_prefix as root dir bug

Initial Comment:
When sys.prefix  or sys.exec_prefix are the root
directory, the reported directory is a null string
instead of "/".

This causes site.py to fail as described in bug 713601.

This patch to Modules/getpath.c inserts a SEP character
into the string if it is empty.

It should work fine on any unix, but I don't have any
python experience on the windows side...

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 17:25

Message:
Logged In: YES 
user_id=580910

What patch?

You seem to have forgotten so check the "yes I really want to upload a 
file" checkbox.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931938&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:27:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:27:49 2004
Subject: [Patches] [ python-Patches-1005123 ] test_curses fails on MacOS X
	10.3
Message-ID: 

Patches item #1005123, was opened at 2004-08-07 14:40
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470

Category: Tests
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
>Assigned to: Michael Hudson (mwh)
Summary: test_curses fails on MacOS X 10.3

Initial Comment:
test_curses fails on MacOS X 10.3.

I'm seeing two failures:

The call to curses.curs_set at line 143 (in module_funcs) fails (that 
is raises curses.error), which the test doesn't expect.  

The test for curses.use_default_colors() (also in module_funcs) 
also fails. curses.has_colors() is False, which probably explains 
why use_default_colors fails.

The attached patch adds a try block around the call to 
curses.curs_set and reindents the test for 
curses.use_default_colors().

WARNING: I've never used curses. 

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 16:27

Message:
Logged In: YES 
user_id=6656

Actually, I think you uploaded the same patch twice, but I've done 
what I suggested anyway :-)

Lib/test/test_curses.py revision 1.8.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 14:58

Message:
Logged In: YES 
user_id=580910

I've guarded the call to curs_set by tigetstr("cnorm"), based on a 
suggestion by mwh.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005123&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:52:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:53:59 2004
Subject: [Patches] [ python-Patches-997626 ]
	httplib.HTTPConnection.request() bug
Message-ID: 

Patches item #997626, was opened at 2004-07-25 17:56
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: John J Lee (jjlee)
>Assigned to: Jeremy Hylton (jhylton)
Summary: httplib.HTTPConnection.request() bug

Initial Comment:
996159 reveals a problem with 
httplib.HTTPConnection.request().

The underlying problem is that, while this method checks 
no explicit Host: header was provided, it fails to do the 
same for Accept-Encoding: and Content-Length:

This patch fixes that.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-27 19:55

Message:
Logged In: YES 
user_id=261020

OK, I have now tested my patch, and uploaded a new one which
is syntactically correct ;-) along with a patch for the test
I added to test_httplib.py.

No doc changes are required.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 18:09

Message:
Logged In: YES 
user_id=261020

Of course, urllib2 should also be fixed not to add Host and 
Content-Length headers (httplib makes a better job of it), but 
that's a separate bug which I'll file separately.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 18:00

Message:
Logged In: YES 
user_id=261020

This is important to get into 2.4, because it breaks urllib2.

I haven't run the tests yet, or done any manual tests.  I'll try 
and do that tomorrow.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 17:58:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 17:58:34 2004
Subject: [Patches] [ python-Patches-1003693 ] Fix for 1002475 (Feedparser
	not handling \r\n correctly)
Message-ID: 

Patches item #1003693, was opened at 2004-08-04 21:27
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Fix for 1002475 (Feedparser not handling \r\n correctly)

Initial Comment:
Python 2.4a1/Anon CVS of 5 Aug 2004.  WinXP SP1, not
that that matters.

This is a patch to fix bug:

[ 1002475 ] email message parser doesn't handle \r\n
correctly
http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475

Basically, FeedParser does a rstrip() on the last
header value, but not any of the others.  Given that
RFC822 wants the headers to end with \r\n, it's likely
that most will, and this means that all the headers
except for the last end with \r.  This one line patch
just does the extra rstrip.

Note that you might want to implement the fix yourself
- it doesn't fit on a line, and so it's wrapped in an
ugly way - maybe you can think of something prettier :)
 This does fix the problem, though (here, at least,
using the test case outlined in the bug report).

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-08-06 02:39

Message:
Logged In: YES 
user_id=43607

I've only tried the patch, not the test, but it seems to
work well.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-04 22:09

Message:
Logged In: YES 
user_id=552329

Second test was in the wrong place, so moving.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-04 21:48

Message:
Logged In: YES 
user_id=552329

Also attached is a patch for test_email.py.  This adds two
new tests (which fail before the FeedParser.py patch, and
pass afterwards).

The first tests that the \r\n characters are correctly removed.
The second is a copy of an existing test to check
continuations with whitespace, but checks if it works with
the continuation as the last header.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-08-04 21:46

Message:
Logged In: YES 
user_id=552329

Attaching new patch, because that one breaks one of the
tests.  The rstrip() needs to be rstrip('\r\n') or it strips
other whitespace that isn't allowed there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003693&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:05:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:05:29 2004
Subject: [Patches] [ python-Patches-996627 ] realpath: resolve symlinks
	before normalizing (bug #990669)
Message-ID: 

Patches item #996627, was opened at 2004-07-23 16:45
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: realpath: resolve symlinks before normalizing (bug #990669)

Initial Comment:
This patch fixes the problem described in
http://python.org/sf/990669 and adds tests for realpath.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 16:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:05:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:05:58 2004
Subject: [Patches] [ python-Patches-996626 ] normpath symlinks doc warning
	(bug #990669)
Message-ID: 

Patches item #996626, was opened at 2004-07-23 16:45
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996626&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: normpath symlinks doc warning (bug #990669)

Initial Comment:
normpath may alter the meaning of a path if it contains
symbolic links. This has been documented in a comment
since 1992, but it should be in the library reference
as well.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 17:05

Message:
Logged In: YES 
user_id=6656

 

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 16:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996626&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:08:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:08:34 2004
Subject: [Patches] [ python-Patches-996627 ] realpath: resolve symlinks
	before normalizing (bug #990669)
Message-ID: 

Patches item #996627, was opened at 2004-07-23 17:45
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470

>Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: realpath: resolve symlinks before normalizing (bug #990669)

Initial Comment:
This patch fixes the problem described in
http://python.org/sf/990669 and adds tests for realpath.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:08:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:08:41 2004
Subject: [Patches] [ python-Patches-996626 ] normpath symlinks doc warning
	(bug #990669)
Message-ID: 

Patches item #996626, was opened at 2004-07-23 17:45
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996626&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: normpath symlinks doc warning (bug #990669)

Initial Comment:
normpath may alter the meaning of a path if it contains
symbolic links. This has been documented in a comment
since 1992, but it should be in the library reference
as well.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 18:05

Message:
Logged In: YES 
user_id=6656

 

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996626&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:28:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:29:24 2004
Subject: [Patches] [ python-Patches-997626 ]
	httplib.HTTPConnection.request() bug
Message-ID: 

Patches item #997626, was opened at 2004-07-25 17:56
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib.HTTPConnection.request() bug

Initial Comment:
996159 reveals a problem with 
httplib.HTTPConnection.request().

The underlying problem is that, while this method checks 
no explicit Host: header was provided, it fails to do the 
same for Accept-Encoding: and Content-Length:

This patch fixes that.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-27 19:55

Message:
Logged In: YES 
user_id=261020

OK, I have now tested my patch, and uploaded a new one which
is syntactically correct ;-) along with a patch for the test
I added to test_httplib.py.

No doc changes are required.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 18:09

Message:
Logged In: YES 
user_id=261020

Of course, urllib2 should also be fixed not to add Host and 
Content-Length headers (httplib makes a better job of it), but 
that's a separate bug which I'll file separately.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 18:00

Message:
Logged In: YES 
user_id=261020

This is important to get into 2.4, because it breaks urllib2.

I haven't run the tests yet, or done any manual tests.  I'll try 
and do that tomorrow.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997626&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:43:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:43:28 2004
Subject: [Patches] [ python-Patches-748126 ] Nails down the semantics of
	dict setitem
Message-ID: 

Patches item #748126, was opened at 2003-06-03 12:57
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Nails down the semantics of dict setitem

Initial Comment:
You could consider accomplishing the same thing in the 
footnotes area, but I didn't see any reason to make the 
reader jump around for this info.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 17:43

Message:
Logged In: YES 
user_id=6656

I agree.  Closing.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-08-07 16:00

Message:
Logged In: YES 
user_id=99874

I asked about this on python-dev. Turns out that the
behavior is the same in CPython and Jython (at least), but
that it is officially undefined in the language (ie, if
someone finds a more efficient way to implement a dict which
happens to alter what happens when assigning to existing
keys, then it might change). Therefore, I think it should
NOT be documented. It's rare that people would create
objects that compare equal and yet care which one is used,
and anyone doing so should know what they're doing well
enough to test it out.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2003-07-04 03:42

Message:
Logged In: YES 
user_id=52572

I think I originally tried to attach a patch which SF dropped 
due to one of its usual bugs.   I think the question was 
whether d[k] = y would unconditionally set the identity of the 
key object in d to k, or whether any previous equal key in 
that "slot" would be preserved.  It's the latter, and the 
current docs don't say which one it is.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-07-04 02:06

Message:
Logged In: YES 
user_id=3066

This report is very vague.  What part of the documentation
are you referring to, and how do you think it should be changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=748126&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 18:57:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 18:57:39 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 17:06
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 17:57

Message:
Logged In: YES 
user_id=6656

OK, take 2.  More documentation, removes the "if (func_name == 
Py_None)" case in func_repr.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-07 14:43

Message:
Logged In: YES 
user_id=21627

These decisions are all fine with me.

As for anonymous functions: It appears that compile.c
2.36/funcobject.c 2.7 introduce the notion of anonymous code
objects (30-Nov-93). compile.c 2.48 (18-Jul-95) takes this
option out again, along with introducing keyword arguments.
So it is probably safe to drop the support for anonymous
functions.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 14:10

Message:
Logged In: YES 
user_id=6656

> Should we require that the new function name is a valid
> identifier?

We could, but I don't really see it being worth the effort
(no attempt is made to ensure that a type's __name__ is a
valid identifier today).

> If not, is an empty string an acceptable function name?

Don't see why not.

> Also, are string subtypes allowed?

Again, don't see why not.

> There should be \versionchanged in the documentation.

Yes.  In fact the documentation of function attributes could
do with being rewritten entirely....

I'll note that all the possibilities you mention are
possiblities today, via new.function.  I'm really not
changing very much.

Agree with Anthony that we don't want to allow unicode.

(While we're at it, I see that func_repr takes into account
that func_name might be Py_None, but I don't think this is
actually possible.  Any ideas?).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-07 11:49

Message:
Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 21:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 19:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 19:06:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 19:06:19 2004
Subject: [Patches] [ python-Patches-1003863 ] adds an index entry for
	__all__ to the tutorial
Message-ID: 

Patches item #1003863, was opened at 2004-08-05 11:31
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003863&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Clinton Roy (clintonroy)
>Assigned to: Michael Hudson (mwh)
Summary: adds an index entry for __all__ to the tutorial

Initial Comment:
a one liner.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-07 18:06

Message:
Logged In: YES 
user_id=6656

Works for me.

Doc/tut/tut.tex revision 1.244

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003863&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 21:22:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 21:22:10 2004
Subject: [Patches] [ python-Patches-836879 ] assert should not generate code
	if optimized
Message-ID: 

Patches item #836879, was opened at 2003-11-05 23:11
Message generated for change (Settings changed) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836879&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Jeremy Hylton (jhylton)
Summary: assert should not generate code if optimized

Initial Comment:
The compiler package in Lib still generates code for
assert statements, even if -O is specified.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836879&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 22:21:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 22:21:32 2004
Subject: [Patches] [ python-Patches-1003861 ] Fix markup in concrete.tex
Message-ID: 

Patches item #1003861, was opened at 2004-08-05 06:22
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003861&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Fix markup in concrete.tex

Initial Comment:
A few minor changes:

  - "PyObject* o" -> "PyObject *o" to be consistent with the
     rest of the file
  - Correct markup for Py_True
  - Remove duplicate description of PyBool_Check


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 16:21

Message:
Logged In: YES 
user_id=11375

Applied; thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003861&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 22:26:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 22:26:52 2004
Subject: [Patches] [ python-Patches-999280 ] Update kwargs in pickle docs to
	match implementations
Message-ID: 

Patches item #999280, was opened at 2004-07-28 05:18
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=999280&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Update kwargs in pickle docs to match implementations

Initial Comment:
The pickle documentation says that the first argument to dump 
and dumps is called "object", but both the pure-Python pickle 
module and (now) the cPickle module call it "obj". The pickle 
module purposely calls it "obj" instead of "object" to avoid 
shadowing the "object" builtin, and the cPickle does likewise to 
maintain API compatibility.

References: pickle.py 1.107, SF #995766

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 16:26

Message:
Logged In: YES 
user_id=11375

Applied; thanks.

You know, you should probably request CVS commit privileges so you can 
make documentation fixes directly.  


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=999280&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 22:31:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 22:32:10 2004
Subject: [Patches] [ python-Patches-702933 ] Kill off docs for unsafe macros
Message-ID: 

Patches item #702933, was opened at 2003-03-13 08:10
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Kill off docs for unsafe macros

Initial Comment:
I'll also attach the patch, but a message body is 
required:
=========================================
==========================
RCS 
file: /cvsroot/python/python/dist/src/Doc/api/memory.tex,
v
retrieving revision 1.2
diff -w -u -r1.2 memory.tex
--- memory.tex	6 Apr 2002 09:14:33 -0000
	1.2
+++ memory.tex	13 Mar 2003 12:56:26 -0000
@@ -195,9 +195,7 @@
 In addition to the functions aimed at handling raw 
memory blocks from
 the Python heap, objects in Python are allocated and 
released with
 \cfunction{PyObject_New()}, \cfunction
{PyObject_NewVar()} and
-\cfunction{PyObject_Del()}, or with their corresponding 
macros
-\cfunction{PyObject_NEW()}, \cfunction
{PyObject_NEW_VAR()} and
-\cfunction{PyObject_DEL()}.
+\cfunction{PyObject_Del()}.
 
 These will be explained in the next chapter on defining 
and
 implementing new object types in C.
Index: newtypes.tex
=========================================
==========================
RCS 
file: /cvsroot/python/python/dist/src/Doc/api/newtypes.te
x,v
retrieving revision 1.21
diff -w -u -r1.21 newtypes.tex
--- newtypes.tex	10 Feb 2003 19:18:21 -0000
	1.21
+++ newtypes.tex	13 Mar 2003 12:56:27 -0000
@@ -62,23 +62,6 @@
   after this call as the memory is no longer a valid 
Python object.
 \end{cfuncdesc}
 
-\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW}{TYPE, 
PyTypeObject *type}
-  Macro version of \cfunction{PyObject_New()}, to gain 
performance at
-  the expense of safety.  This does not check \var{type} 
for a \NULL{}
-  value.
-\end{cfuncdesc}
-
-\begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW_VAR}
{TYPE, PyTypeObject *type,
-                                                int size}
-  Macro version of \cfunction{PyObject_NewVar()}, to 
gain performance
-  at the expense of safety.  This does not check \var
{type} for a
-  \NULL{} value.
-\end{cfuncdesc}
-
-\begin{cfuncdesc}{void}{PyObject_DEL}{PyObject *op}
-  Macro version of \cfunction{PyObject_Del()}.
-\end{cfuncdesc}
-
 \begin{cfuncdesc}{PyObject*}{Py_InitModule}{char 
*name,
                                             PyMethodDef *methods}
   Create a new module object based on a name and 
table of functions,


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 16:31

Message:
Logged In: YES 
user_id=11375

Tim made the suggestion that only the core should use them: 
http://mail.python.org/pipermail/python-dev/2003-March/033993.html

Thomas Heller disagreed.  How should we rule on this?

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2003-07-03 22:37

Message:
Logged In: YES 
user_id=52572

I've forgotten, frankly.  You might check python-dev around 
this date.  Seems like Guido may have agreed that these 
macros were really not meant to be touched by users and 
shouild be deprecated, but I don't recall.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-07-03 21:00

Message:
Logged In: YES 
user_id=3066

I'm not sure what you're suggesting with this patch.  Could
you explain the intention?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=702933&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 22:59:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 22:59:40 2004
Subject: [Patches] [ python-Patches-988642 ] Update HTTPRespnse.length
Message-ID: 

Patches item #988642, was opened at 2004-07-10 17:16
Message generated for change (Comment added) made by akuchling
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: A.M. Kuchling (akuchling)
Date: 2004-08-07 16: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 18: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  Sat Aug  7 23:05:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 23:05:20 2004
Subject: [Patches] [ python-Patches-836088 ] Update htmllib to HTML 4.01
Message-ID: 

Patches item #836088, was opened at 2003-11-04 16:57
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Update htmllib to HTML 4.01

Initial Comment:
The attached patch adds methods for all of the HTML 4.01 
elements and rearranges things a bit.  

This version is incomplete.  Still to do:
* Expand test suite to exercise all the methods.
* Change documentation to match.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 23:38:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 23:38:24 2004
Subject: [Patches] [ python-Patches-862531 ] installing modules are
	explained in old filenames
Message-ID: 

Patches item #862531, was opened at 2003-12-18 16:24
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: A.M. Kuchling (akuchling)
Summary: installing modules are explained in old filenames

Initial Comment:
In the document of "Installing Python Modules", directory 
and file names are based on Python 2.0.

For example:
  coff2omf python20.lib python20_bcpp.lib

This patch is to change these version numbers up-to-
date.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 17:38

Message:
Logged In: YES 
user_id=11375

Patch applied to both CVS head and 2.3 branch; thanks!

(You might want to consider asking for CVS commit privileges so that you 
can work on the documentation.)


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-07-10 09:24

Message:
Logged In: YES 
user_id=2772

patch applies cleanly to cvs head

"make pdf" still builds paper-letter/inst.pdf on my system
after the patch

I noticed two version-related problems in inst.tex after the
patch:
2.4. The Start Menu instruction mentions version 2.1, and
the interactive shell session is from 1.5.2
6.2. in the "coff2omf" line, only one "20" was changed to "24"

3.4. Should the MacOS 9 section be removed from the
documentation?  We aren't building for this OS anymore, I
thought.

I think this patch is worth including, but with the two
items above fixed too.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-07-10 09:24

Message:
Logged In: YES 
user_id=2772

patch applies cleanly to cvs head

"make pdf" still builds paper-letter/inst.pdf on my system
after the patch

I noticed two version-related problems in inst.tex after the
patch:
2.4. The Start Menu instruction mentions version 2.1, and
the interactive shell session is from 1.5.2
6.2. in the "coff2omf" line, only one "20" was changed to "24"

3.4. Should the MacOS 9 section be removed from the
documentation?  We aren't building for this OS anymore, I
thought.

I think this patch is worth including, but with the two
items above fixed too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 23:40:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 23:40:07 2004
Subject: [Patches] [ python-Patches-888380 ] popen2.popen2() 'cmd' list
	syntax docstring
Message-ID: 

Patches item #888380, was opened at 2004-01-31 19:44
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Connelly aka shellreef (jeffconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen2.popen2() 'cmd' list syntax docstring

Initial Comment:
This simple patch documents using popen2() with a list
as the first argument. Currently this feature is not
documented. It is good practice to use the list-popen2
as it avoids shell interpretation.



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 17:39

Message:
Logged In: YES 
user_id=11375

Just a reminder -- could you please update this patch so that it can be 
applied?


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-07-10 09:14

Message:
Logged In: YES 
user_id=2772

Please resubmit the patch in context or unified diff format.
 ed-format diffs generally won't apply when any other
changes have been made in that file in the meantime.

The same or similar documentation change should also be
applied to Popen3.__init__, Popen4.__init__ (which does't
exist yet), popen3(), and popoen4()

The line number in your version of the patch seems to
indicate that the change was made within the 'if
sys.platform[:3] == "win" ...:' block, which is where the
advice doesn't apply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 23:50:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 23:50:52 2004
Subject: [Patches] [ python-Patches-784089 ] A program to scan python files
	and list those require coding
Message-ID: 

Patches item #784089, was opened at 2003-08-06 06:47
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470

Category: Demos and tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Oleg Broytmann (phd)
Assigned to: Nobody/Anonymous (nobody)
Summary: A program to scan python files and list those require coding

Initial Comment:
A program to scan python files (recursively) and list
those that require coding directive (pseudocomment)
because there non-ASCII characters in the file
(including comments).

The program treats files as python files if the
extension is .py or there is "python" in the first line
of the file.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-07 17:50

Message:
Logged In: YES 
user_id=11375

So, does something need to be done with this script, like adding it to the 
distribution?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-08-06 08:36

Message:
Logged In: YES 
user_id=38388

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784089&group_id=5470
From noreply at sourceforge.net  Sat Aug  7 23:53:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug  7 23:53:40 2004
Subject: [Patches] [ python-Patches-836088 ] Update htmllib to HTML 4.01
Message-ID: 

Patches item #836088, was opened at 2003-11-04 22:57
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Update htmllib to HTML 4.01

Initial Comment:
The attached patch adds methods for all of the HTML 4.01 
elements and rearranges things a bit.  

This version is incomplete.  Still to do:
* Expand test suite to exercise all the methods.
* Change documentation to match.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-07 23:53

Message:
Logged In: YES 
user_id=469548

I used the list at
http://www.w3.org/TR/html4/index/elements.html to check
whether the right functions were used:

col, frame, input and param should have do_tag() methods
instead of start/end_tag(): they are empty tags in HTML 4.01.

dd, dt and li should use start/end_tag() instead of
do_tag(). They have an optional end tag in HTML 4.01.

Oh, and I couldn't find a method for the 'div' element!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470
From noreply at sourceforge.net  Sun Aug  8 13:08:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug  8 13:08:20 2004
Subject: [Patches] [ python-Patches-1005461 ] property to get the docstring
	from fget
Message-ID: 

Patches item #1005461, was opened at 2004-08-08 11: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=1005461&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: property to get the docstring from fget

Initial Comment:
Allow property objects to use the fget function's docstring if a 
property docstring wasn't specified. This was suggested by 
someone on python-dev or c.l.py, but I don't remember who it was 
(sorry). Function docstrings are easier to write (read: prettier) than 
explicit doc= arguments, so this should make more properties 
have docstrings, sometimes automagically (I know it will for my 
code, anyway). It gets even better with syntatic sugar for 
decorators; read-only properties can now be defined, including 
docstring, with just one function:

  @property
    def golden(self):
        """The Golden Ratio. (Don't ask why this is a property.)"""
        return (1 + math.sqrt(5)) / 2

The doc part of the patch also improves some markup in the 
vicinity.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005461&group_id=5470
From noreply at sourceforge.net  Sun Aug  8 13:22:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug  8 13:22:46 2004
Subject: [Patches] [ python-Patches-1005465 ] Markup tweaks to @deco
	examples in libref
Message-ID: 

Patches item #1005465, was opened at 2004-08-08 11: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=1005465&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Markup tweaks to @deco examples in libref

Initial Comment:
Trivial markup tweaks to the @staticmethod and @classmethod 
examples in the library reference:

  - Use \versionadded instead of inlining an inconsistent version of 
that text
  - Add the @decos-added-in-2.4 line to the staticmethod section 
as well (previously, it was only on classmethod)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005465&group_id=5470
From noreply at sourceforge.net  Sun Aug  8 13:29:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug  8 13:30:00 2004
Subject: [Patches] [ python-Patches-1005466 ] fix inspect.getargs() crash on
	def foo((bar)) (bug #891637)
Message-ID: 

Patches item #1005466, was opened at 2004-08-08 13:29
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=1005466&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix inspect.getargs() crash on def foo((bar)) (bug #891637)

Initial Comment:
inspect.getargs() assumes that Python generates the
UNPACK_TUPLE or UNPACK_SEQUENCE bytecodes when a
sublist is used. However, when the sublist has length 1
Python just optimizes away those bytecodes. It only
generates a STORE_FAST, even though it does take the
path used for sublists. This patch fixes this case in
inspect.getargs().

This fixes http://python.org/sf/891637: pydoc crashes
on a class property.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005466&group_id=5470
From noreply at sourceforge.net  Sun Aug  8 13:34:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug  8 13:34:35 2004
Subject: [Patches] [ python-Patches-1005468 ] Disambiguate "min() or max()"
	exception string
Message-ID: 

Patches item #1005468, was opened at 2004-08-08 11:34
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=1005468&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Disambiguate "min() or max()" exception string

Initial Comment:
The min and max builtins are implemented by the same C 
function, and one of the exception strings is:

   ValueError: min() or max() arg is an empty sequence

which is unsurprisingly unhelpful for a statement that calls both of 
them on different sequences. The function knows which operation 
it's implementing it, so why not display the right one?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005468&group_id=5470
From noreply at sourceforge.net  Sun Aug  8 14:32:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug  8 14:32:49 2004
Subject: [Patches] [ python-Patches-1005491 ] use __name__ == '__main__' in
	tools/scripts (bug #624893)
Message-ID: 

Patches item #1005491, was opened at 2004-08-08 14: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=1005491&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: use __name__ == '__main__' in tools/scripts (bug #624893)

Initial Comment:
Many scripts in Tools/scripts don't use the __name__ ==
'__main__' check before running. This means pydoc can't
show their documentation. This patch adds this check to
all files in Tools/scripts and, for some, puts most of
the script in a main() function.

This fixes http://python.org/sf/624893.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005491&group_id=5470
From noreply at sourceforge.net  Sun Aug  8 20:40:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug  8 20:40:12 2004
Subject: [Patches] [ python-Patches-720188 ] proposed patch for
	posixpath.py: getctime()
Message-ID: 

Patches item #720188, was opened at 2003-04-12 07:42
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720188&group_id=5470

Category: Modules
Group: Python 2.1.2
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Jose' Manuel Sebrosa (sebrosa)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: proposed patch for posixpath.py: getctime()

Initial Comment:
I am using python 2.1.3 from debian woody.

The module posixpath defines getatime() and getmtime()
functions, but it lacks a similar getctime().

Here is my proposed patch to add getctime() to posixpath.


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-08-08 13:40

Message:
Logged In: YES 
user_id=149084

getctime() was added to posixpath.py at Rev 1.56 31Dec02 and
first appeared in 2.3.  Was not backported to 2.2.

Closing as out of date.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720188&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 02:40:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 02:40:24 2004
Subject: [Patches] [ python-Patches-1003535 ] Simple File fix for Windows
	Runtime incompatability
Message-ID: 

Patches item #1003535, was opened at 2004-08-04 16:17
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003535&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Schwartz (mdjeremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple File fix for Windows Runtime incompatability

Initial Comment:

Problem:

PyRun_SimpleFile - Using this function on Windows with
MSVC7 (VS .NET) causes a crash.

Reason: 

1)Pre built binaries link to msvcrt.dll. New version of
MSVC link to msvcrt71.dll. The FILE structure is
different across the two versions of runtime library. 

2) If python23.dll is rebuilt using the latest binary,
and issue exist where passing in FILE * still causes
the runtime library to throw an exception due to
running in the dll's context.

Solution:

Remove both of these problems by adding a new function
that only takes the filename (future maybe fopen flags)
and have the dll open the file itself and pass it on.

New function added to pythonrun.c and pythonrun.h

int
PyRun_SimpleFileWithOpen(const char *filename)

Takes just the file name, opens the file and then pass
it on.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-08 20:40

Message:
Logged In: YES 
user_id=31435

There appear to be all sorts of things in the patch that don't 
have anything to do with the new function.  Is that 
intentional?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003535&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 04:06:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 04:06:47 2004
Subject: [Patches] [ python-Patches-1005461 ] property to get the docstring
	from fget
Message-ID: 

Patches item #1005461, was opened at 2004-08-08 11:08
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005461&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: property to get the docstring from fget

Initial Comment:
Allow property objects to use the fget function's docstring if a 
property docstring wasn't specified. This was suggested by 
someone on python-dev or c.l.py, but I don't remember who it was 
(sorry). Function docstrings are easier to write (read: prettier) than 
explicit doc= arguments, so this should make more properties 
have docstrings, sometimes automagically (I know it will for my 
code, anyway). It gets even better with syntatic sugar for 
decorators; read-only properties can now be defined, including 
docstring, with just one function:

  @property
    def golden(self):
        """The Golden Ratio. (Don't ask why this is a property.)"""
        return (1 + math.sqrt(5)) / 2

The doc part of the patch also improves some markup in the 
vicinity.

----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-09 02:06

Message:
Logged In: YES 
user_id=908995

Oops, now that I'm sufficiently awake, it's pretty obvious that the patch 
is broken--it leaks a reference every time the new code runs. Mea culpa! 
Corrected patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005461&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 06:48:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 06:48:57 2004
Subject: [Patches] [ python-Patches-1003700 ] add socketpair function to
	socket module
Message-ID: 

Patches item #1003700, was opened at 2004-08-05 02:09
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: add socketpair function to socket module

Initial Comment:
Adds a socketpair() function to the socketmodule.c.  
The function returns two socket objects.

Contains some simple unit tests that check the return
value from socketpair is actually two functioning sockets.

Outstanding question is whether the family, type, proto
arguments should be kwargs as per socket() function, or
positional as per fromfd() function.  If kwargs, then
it is arguable that the fromfd() arguments should be
changed (in another patch).


----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-09 04:48

Message:
Logged In: YES 
user_id=28658

Have addressed all of the issues with the v2 patch.  Will
commit this now.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 07:10

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply. Make sure to
- add \versionadded{2.4} into the documentation
- add an entry to Misc/NEWS

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 06:53:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 06:53:27 2004
Subject: [Patches] [ python-Patches-1003700 ] add socketpair function to
	socket module
Message-ID: 

Patches item #1003700, was opened at 2004-08-05 02:09
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470

Category: Modules
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: add socketpair function to socket module

Initial Comment:
Adds a socketpair() function to the socketmodule.c.  
The function returns two socket objects.

Contains some simple unit tests that check the return
value from socketpair is actually two functioning sockets.

Outstanding question is whether the family, type, proto
arguments should be kwargs as per socket() function, or
positional as per fromfd() function.  If kwargs, then
it is arguable that the fromfd() arguments should be
changed (in another patch).


----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-09 04:53

Message:
Logged In: YES 
user_id=28658

Commited the patch.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-09 04:48

Message:
Logged In: YES 
user_id=28658

Have addressed all of the issues with the v2 patch.  Will
commit this now.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 07:10

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply. Make sure to
- add \versionadded{2.4} into the documentation
- add an entry to Misc/NEWS

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 07:34:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 07:34:10 2004
Subject: [Patches] [ python-Patches-1005778 ] Avoid seg fault if list object
	is modified during list.index
Message-ID: 

Patches item #1005778, was opened at 2004-08-09 05:34
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=1005778&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: Avoid seg fault if list object is modified during list.index

Initial Comment:
The list.index implementation can be coerced into indexing past 
the end of ob_item. It calls PyObject_RichCompareBool (which 
may call into Python) in a loop, but the loop counter is only 
checked against a cached copy of the list size, so if the list 
shrinks during the comparison, the next counter value may be out 
of bounds. The patch includes a test case that causes unpatched 
Pythons to seg fault.

I checked the other uses of PyObject_RichCompareBool in 
listobject.c, and all of them look safe (but I mostly glossed over 
the mergesort uses, which I'm sure have been painstakingly 
verified and tested by its author).

(NB: The change to list_tests.py references the revision number of 
the post-patch listobject.c. When this is committed, please make 
sure that, that revision number is still current.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005778&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 07:54:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 07:54:31 2004
Subject: [Patches] [ python-Patches-1003700 ] add socketpair function to
	socket module
Message-ID: 

Patches item #1003700, was opened at 2004-08-05 04:09
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470

Category: Modules
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: add socketpair function to socket module

Initial Comment:
Adds a socketpair() function to the socketmodule.c.  
The function returns two socket objects.

Contains some simple unit tests that check the return
value from socketpair is actually two functioning sockets.

Outstanding question is whether the family, type, proto
arguments should be kwargs as per socket() function, or
positional as per fromfd() function.  If kwargs, then
it is arguable that the fromfd() arguments should be
changed (in another patch).


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-09 07:54

Message:
Logged In: YES 
user_id=21627

In the future, please add the version numbers of the changed
files into the SF patch/bug report.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-09 06:53

Message:
Logged In: YES 
user_id=28658

Commited the patch.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-09 06:48

Message:
Logged In: YES 
user_id=28658

Have addressed all of the issues with the v2 patch.  Will
commit this now.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 09:10

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply. Make sure to
- add \versionadded{2.4} into the documentation
- add an entry to Misc/NEWS

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 08:13:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 08:13:33 2004
Subject: [Patches] [ python-Patches-1003700 ] add socketpair function to
	socket module
Message-ID: 

Patches item #1003700, was opened at 2004-08-05 02:09
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470

Category: Modules
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: add socketpair function to socket module

Initial Comment:
Adds a socketpair() function to the socketmodule.c.  
The function returns two socket objects.

Contains some simple unit tests that check the return
value from socketpair is actually two functioning sockets.

Outstanding question is whether the family, type, proto
arguments should be kwargs as per socket() function, or
positional as per fromfd() function.  If kwargs, then
it is arguable that the fromfd() arguments should be
changed (in another patch).


----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-09 06:13

Message:
Logged In: YES 
user_id=28658

Sorry about that.  Here they are:

configure.in; new revision 1.464
pyconfig.h.in; new revision 1.102
Doc/lib/libsocket.tex; new revision 1.85 (fix in 1.86)
Lib/socket.py; new revision 1.45
Lib/test/test_socket.py; new revision 1.73
Misc/NEWS; new revision 1.1081
Modules/socketmodule.c; new revision 1.299

(I looked for an example in on eof your patch commits - did
not have any revisions...  had to look at tim_one for
example :-).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-09 05:54

Message:
Logged In: YES 
user_id=21627

In the future, please add the version numbers of the changed
files into the SF patch/bug report.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-09 04:53

Message:
Logged In: YES 
user_id=28658

Commited the patch.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-09 04:48

Message:
Logged In: YES 
user_id=28658

Have addressed all of the issues with the v2 patch.  Will
commit this now.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 07:10

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply. Make sure to
- add \versionadded{2.4} into the documentation
- add an entry to Misc/NEWS

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003700&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 11:31:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 11:31:06 2004
Subject: [Patches] [ python-Patches-1005857 ] replacing rfc822.formatdate
Message-ID: 

Patches item #1005857, was opened at 2004-08-09 19:31
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=1005857&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: replacing rfc822.formatdate

Initial Comment:
If we're going to deprecate rfc822, we should stop
using it.
The following patch makes urllib and urllib2 stop using it
for date strings. Unfortunately HTTP insists on the "GMT" 
notation for the timezone, not "-0000"[1], so
email.Utils.formatdate
grew a new flag "asciigmt". 

Assigning to Barry, as email is his baby.


[1]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005857&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 12:03:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 12:04:01 2004
Subject: [Patches] [ python-Patches-1001864 ] Logger file objects
Message-ID: 

Patches item #1001864, was opened at 2004-08-02 18:35
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
>Assigned to: Vinay Sajip (vsajip)
Summary: Logger file objects

Initial Comment:
The logger can return a file like object for each error
level.
These file objects can be sent to any function
expecting a file object.

Example:
>> import logging
>> logging.basicConfig()
>> logger = logging.getLogger()
>> err = logger.getFileObject(logging.ERROR)
>> print >> err, "This is an error"
ERROR:root:This is an error
ERROR:root:

>> err.flush()
>> err.close()


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 20:03

Message:
Logged In: YES 
user_id=29957

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 20:03

Message:
Logged In: YES 
user_id=29957




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 12:15:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 12:15:52 2004
Subject: [Patches] [ python-Patches-983206 ] Allow ldshared to be overridden
	by environment var
Message-ID: 

Patches item #983206, was opened at 2004-07-01 16:18
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983206&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Liam Routt (liam_routt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow ldshared to be overridden by environment var

Initial Comment:
At present the ldshared executible is set only by
locating it in the python Makefile (there is a fallback
if it is not found, as well). While that works in many
cases, it may be that one needs to set the ldshared to
agree with a compiler/linker other than the one python
was compiled with. You can set CC, but when creating
shared objects you are stuck with whatever python was
compiled with.

The patch simply checks for LDSHARED in the current
environment, and if it is present, it uses it. This is
the same behaviour (and method) as for CC and CXX.

Note that I'm indicating this is for 2.3, but I've
browsed CVS and found sysconfig.py to be identical in
this area of the code.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 20:15

Message:
Logged In: YES 
user_id=29957

I'm inclined to accept this patch, if only because Python's
own setup.py has a similar hack in it already! 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=983206&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 12:56:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 12:56:26 2004
Subject: [Patches] [ python-Patches-1005891 ] support --with-tsc on PPC
Message-ID: 

Patches item #1005891, was opened at 2004-08-09 11: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=1005891&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: support --with-tsc on PPC

Initial Comment:
This patch makes the --with-tsc configure option to enable 
low-level profiling of the VM work on PPC (only tested on OS 
X, but should work on linux/ppc too).

Also adds a description of the build to Misc/SpecialBuilds.txt, 
which goes into more detail about the PPC version because I 
know rather more about the PPC architecture than the 
Pentium.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005891&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 12:57:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 12:57:44 2004
Subject: [Patches] [ python-Patches-1005892 ] test_curses bugs
Message-ID: 

Patches item #1005892, was opened at 2004-08-09 17:57
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=1005892&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandr Zamaraev (shura_zam)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_curses bugs

Initial Comment:
I find 2 bugs in test_curses.py
1) in line 110 setscrreg(10,15)
- cursor mast place in line10-15
2) in line 181 pair_content(curses.COLOR_PAIRS)
- argument pair_content mast by less COLOR_PAIRS
constant

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005892&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 13:05:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 13:06:00 2004
Subject: [Patches] [ python-Patches-1005895 ] curses for win32
Message-ID: 

Patches item #1005895, was opened at 2004-08-09 18:05
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=1005895&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandr Zamaraev (shura_zam)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses for win32

Initial Comment:
I have paths for compile _curses module.
I use 
compiler - mingw32 v3.3.1
curses library - Public Domain Curses (PDCurses 2.6)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005895&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 13:51:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 13:52:01 2004
Subject: [Patches] [ python-Patches-1005913 ] Patch to allow building of
	paper-*/dist.pdf
Message-ID: 

Patches item #1005913, was opened at 2004-08-09 06:51
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=1005913&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to allow building of paper-*/dist.pdf

Initial Comment:
Building dist.pdf I get a traceback which ends
  File
"/usr/src/cvs-src/python/dist/src/Doc/tools/toc2bkm.py",
line 68, in parse_toc
    direction = _transition_map[(level, stype)]
KeyError: ('section', 'subsubsection')

The error seems to exist because the structure of the
document has
\section{API Reference}
...
\subsubsection{something else}
without an intervening \subsection.  

This patch fixes the problem by making the items under
API reference all \subsection{}s, which may or may not
be what was intended.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005913&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 13:53:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 13:53:35 2004
Subject: [Patches] [ python-Patches-1005913 ] Patch to allow building of
	paper-*/dist.pdf
Message-ID: 

Patches item #1005913, was opened at 2004-08-09 06:51
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005913&group_id=5470

>Category: Documentation
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to allow building of paper-*/dist.pdf

Initial Comment:
Building dist.pdf I get a traceback which ends
  File
"/usr/src/cvs-src/python/dist/src/Doc/tools/toc2bkm.py",
line 68, in parse_toc
    direction = _transition_map[(level, stype)]
KeyError: ('section', 'subsubsection')

The error seems to exist because the structure of the
document has
\section{API Reference}
...
\subsubsection{something else}
without an intervening \subsection.  

This patch fixes the problem by making the items under
API reference all \subsection{}s, which may or may not
be what was intended.

----------------------------------------------------------------------

>Comment By: Jeff Epler (jepler)
Date: 2004-08-09 06:53

Message:
Logged In: YES 
user_id=2772

Oops, I forgot to set the category & group!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005913&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 14:47:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 14:47:22 2004
Subject: [Patches] [ python-Patches-1001864 ] Logger file objects
Message-ID: 

Patches item #1001864, was opened at 2004-08-02 11:35
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Vinay Sajip (vsajip)
Summary: Logger file objects

Initial Comment:
The logger can return a file like object for each error
level.
These file objects can be sent to any function
expecting a file object.

Example:
>> import logging
>> logging.basicConfig()
>> logger = logging.getLogger()
>> err = logger.getFileObject(logging.ERROR)
>> print >> err, "This is an error"
ERROR:root:This is an error
ERROR:root:

>> err.flush()
>> err.close()


----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2004-08-09 15:47

Message:
Logged In: YES 
user_id=358087

Hope it works now...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 13:03

Message:
Logged In: YES 
user_id=29957

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 13:03

Message:
Logged In: YES 
user_id=29957




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 15:37:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 15:37:38 2004
Subject: [Patches] [ python-Patches-931938 ] prefix and exec_prefix as root
	dir bug
Message-ID: 

Patches item #931938, was opened at 2004-04-08 14:04
Message generated for change (Comment added) made by goertzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931938&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Goertzen (goertzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: prefix and exec_prefix as root dir bug

Initial Comment:
When sys.prefix  or sys.exec_prefix are the root
directory, the reported directory is a null string
instead of "/".

This causes site.py to fail as described in bug 713601.

This patch to Modules/getpath.c inserts a SEP character
into the string if it is empty.

It should work fine on any unix, but I don't have any
python experience on the windows side...

----------------------------------------------------------------------

>Comment By: Daniel Goertzen (goertzen)
Date: 2004-08-09 08:37

Message:
Logged In: YES 
user_id=843814

Oops.  Another try...

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 10:25

Message:
Logged In: YES 
user_id=580910

What patch?

You seem to have forgotten so check the "yes I really want to upload a 
file" checkbox.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=931938&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 16:59:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 17:04:40 2004
Subject: [Patches] [ python-Patches-1006003 ] Cygwin standard module build
	problems
Message-ID: 

Patches item #1006003, was opened at 2004-08-09 06: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=1006003&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin standard module build problems

Initial Comment:
The following modules:

strop
cPickle
readline

do not build cleanly under Cygwin due to missing
PyAPI_FUNC/PyAPI_DATA macros.

The attached patch fixes these build problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 17:04:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 17:05:51 2004
Subject: [Patches] [ python-Patches-1006003 ] Cygwin standard module build
	problems
Message-ID: 

Patches item #1006003, was opened at 2004-08-09 06:59
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin standard module build problems

Initial Comment:
The following modules:

strop
cPickle
readline

do not build cleanly under Cygwin due to missing
PyAPI_FUNC/PyAPI_DATA macros.

The attached patch fixes these build problems.


----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2004-08-09 07:04

Message:
Logged In: YES 
user_id=86216

Committed as:

Include/pystrtod.h 2.2
Include/pythonrun.h  2.63


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 17:04:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 17:06:59 2004
Subject: [Patches] [ python-Patches-1006003 ] Cygwin standard module build
	problems
Message-ID: 

Patches item #1006003, was opened at 2004-08-09 06:59
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470

Category: Build
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin standard module build problems

Initial Comment:
The following modules:

strop
cPickle
readline

do not build cleanly under Cygwin due to missing
PyAPI_FUNC/PyAPI_DATA macros.

The attached patch fixes these build problems.


----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2004-08-09 07:04

Message:
Logged In: YES 
user_id=86216

Committed as:

Include/pystrtod.h 2.2
Include/pythonrun.h  2.63


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2004-08-09 07:04

Message:
Logged In: YES 
user_id=86216

Committed as:

Include/pystrtod.h 2.2
Include/pythonrun.h  2.63


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 16:59:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 18:49:12 2004
Subject: [Patches] [ python-Patches-1006003 ] Cygwin standard module build
	problems
Message-ID: 

Patches item #1006003, was opened at 2004-08-09 06: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=1006003&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin standard module build problems

Initial Comment:
The following modules:

strop
cPickle
readline

do not build cleanly under Cygwin due to missing
PyAPI_FUNC/PyAPI_DATA macros.

The attached patch fixes these build problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 17:04:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 19:01:17 2004
Subject: [Patches] [ python-Patches-1006003 ] Cygwin standard module build
	problems
Message-ID: 

Patches item #1006003, was opened at 2004-08-09 06:59
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470

Category: Build
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin standard module build problems

Initial Comment:
The following modules:

strop
cPickle
readline

do not build cleanly under Cygwin due to missing
PyAPI_FUNC/PyAPI_DATA macros.

The attached patch fixes these build problems.


----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2004-08-09 07:04

Message:
Logged In: YES 
user_id=86216

Committed as:

Include/pystrtod.h 2.2
Include/pythonrun.h  2.63


----------------------------------------------------------------------

Comment By: Jason Tishler (jlt63)
Date: 2004-08-09 07:04

Message:
Logged In: YES 
user_id=86216

Committed as:

Include/pystrtod.h 2.2
Include/pythonrun.h  2.63


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006003&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 19:31:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 19:31:45 2004
Subject: [Patches] [ python-Patches-1005491 ] use __name__ == '__main__' in
	tools/scripts (bug #624893)
Message-ID: 

Patches item #1005491, was opened at 2004-08-08 08:32
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005491&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: A.M. Kuchling (akuchling)
Summary: use __name__ == '__main__' in tools/scripts (bug #624893)

Initial Comment:
Many scripts in Tools/scripts don't use the __name__ ==
'__main__' check before running. This means pydoc can't
show their documentation. This patch adds this check to
all files in Tools/scripts and, for some, puts most of
the script in a main() function.

This fixes http://python.org/sf/624893.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-09 13:31

Message:
Logged In: YES 
user_id=11375

I was surprised to see that you haven't got checkin
privileges (or did I miss your ID on the SF list?); have you
considered requesting privileges?

Committed to CVS head as the following revisions:

byteyears.py: 1.11, checkpyc.py: 1.11, classfix.py: 1.14,
copytime.py:
1.6, crlf.py: 1.5, cvsfiles.py: 1.6, diff.py: 1.3,
dutree.py: 1.14,
findlinksto.py: 1.10, fixcid.py: 1.12, fixheader.py: 1.7,
fixps.py:
1.8, google.py: 1.3, gprof2html.py: 1.2, h2py.py: 1.19,
idle: 1.2,
ifdef.py: 1.7, lfcr.py: 1.5, linktree.py: 1.7, lll.py: 1.6,
logmerge.py: 1.13, methfix.py: 1.9, mkreal.py: 1.8,
objgraph.py: 1.8, pathfix.py: 1.7, pdeps.py: 1.7, ptags.py:
1.9, pydoc: 1.3,
pydocgui.pyw: 1.2, setup.py: 1.4, suff.py: 1.8, treesync.py:
1.7,
which.py: 1.14, xxci.py: 1.16


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005491&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 19:34:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 19:34:29 2004
Subject: [Patches] [ python-Patches-1005892 ] test_curses bugs
Message-ID: 

Patches item #1005892, was opened at 2004-08-09 06:57
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005892&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandr Zamaraev (shura_zam)
>Assigned to: A.M. Kuchling (akuchling)
Summary: test_curses bugs

Initial Comment:
I find 2 bugs in test_curses.py
1) in line 110 setscrreg(10,15)
- cursor mast place in line10-15
2) in line 181 pair_content(curses.COLOR_PAIRS)
- argument pair_content mast by less COLOR_PAIRS
constant

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005892&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 19:36:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 19:37:03 2004
Subject: [Patches] [ python-Patches-1005465 ] Markup tweaks to @deco
	examples in libref
Message-ID: 

Patches item #1005465, was opened at 2004-08-08 07:22
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005465&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Markup tweaks to @deco examples in libref

Initial Comment:
Trivial markup tweaks to the @staticmethod and @classmethod 
examples in the library reference:

  - Use \versionadded instead of inlining an inconsistent version of 
that text
  - Add the @decos-added-in-2.4 line to the staticmethod section 
as well (previously, it was only on classmethod)

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-09 13:36

Message:
Logged In: YES 
user_id=11375

Committed to the trunk; thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005465&group_id=5470
From noreply at sourceforge.net  Mon Aug  9 23:32:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug  9 23:32:30 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23: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=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 00:05:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 00:05:20 2004
Subject: [Patches] [ python-Patches-1006238 ] cross compile patch
Message-ID: 

Patches item #1006238, was opened at 2004-08-09 17:05
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=1006238&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Goertzen (goertzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cross compile patch

Initial Comment:
Here's a cross compile patch I prepared a while ago but
never got around to submitting.  I've been using it
happily for months to cross compile python for embedded
systems.

Below is a descriptive excerpt from the patch.  Also
note that the patch modifies configure.in, but not
configure.  You will need to regenerate configure with
something like 

autoconf configure.in >configure

This patch is inpsired from work by Klaus Reimer at
http://www.ailis.de/~k/docs/crosscompiling/python.php

+ Cross Compiling
+ ---------------
+ 
+ Python can be cross compiled by supplying different
--host and --build
+ parameters to configure.  (Python is compiled on the
"build" system
+ and executed on the "host" system, in case you forgot
:).  Python is
+ tricky to cross compile because it needs to execute
parts of itself
+ during construction.  To work around this, make's
VPATH feature is
+ used to compile a native python in the subdirectory
"buildpython".
+ When parts of python need to be executed during
construction, the
+ "buildpython" versions are used.
+ 
+ A consequence of using the VPATH feature is that you
may not do a
+ cross compile build in the source directory.  In
other words, do this:
+ 
+ mkdir mydir
+ cd mydir
+ ../Python/configure --host=powerpc-405-linux-gnu
--build=i686-pc-linux-gnu
+ make
+ 
+ Cross compiling works well under linux, mileage may
vary for other
+ platforms.
+ 
+ A few reminders on using configure to cross compile:
+ - Cross compile tools must be in the PATH.
+ - Cross compile tools must be prefixed with the host type
+ (ie powerpc-405-linux-gnu-cc,
powerpc-405-linux-gnu-ranlib, ...)
+ - CC, CXX, AR, and RANLIB must be undefined when
running configure and
+ make.  Configure will detect them.
+ 
+ If you need a cross compiler, check out Dan Kegel's
crosstool:
+ http://www.kegel.com/crosstool
+ 
+ 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 07:00:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 07:01:04 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 13:19:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 13:19:52 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 13:20:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 13:20:48 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Settings changed) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Deleted
Resolution: Wont Fix
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 17:00:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 17:00:59 2004
Subject: [Patches] [ python-Patches-1006629 ] Match Solaris def'n of
	_XOPEN_SOURCE
Message-ID: 

Patches item #1006629, was opened at 2004-08-10 10:00
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=1006629&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Martin v. L?wis (loewis)
Summary: Match Solaris def'n of _XOPEN_SOURCE

Initial Comment:
Per discussion on python-dev attached is a patch that
causes the _XOPEN_SOURCE definition to match that
defined by G++ on Solaris.  This is the simplest
patch I could come up with.  Perhaps better would be 
to discover the value and use that instead of simply
setting it to 500.  My configure skills weren't up to the
task though.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006629&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 17:49:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 17:49:53 2004
Subject: [Patches] [ python-Patches-1001864 ] Logger file objects
Message-ID: 

Patches item #1001864, was opened at 2004-08-02 08:35
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Vinay Sajip (vsajip)
Summary: Logger file objects

Initial Comment:
The logger can return a file like object for each error
level.
These file objects can be sent to any function
expecting a file object.

Example:
>> import logging
>> logging.basicConfig()
>> logger = logging.getLogger()
>> err = logger.getFileObject(logging.ERROR)
>> print >> err, "This is an error"
ERROR:root:This is an error
ERROR:root:

>> err.flush()
>> err.close()


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-08-10 15:49

Message:
Logged In: YES 
user_id=308438

Nice, but I have a question about isatty. Is it needed?
According to the docs for file-like objects, it should not
be implemented unless associated with a real file or device.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-08-09 12:47

Message:
Logged In: YES 
user_id=358087

Hope it works now...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 10:03

Message:
Logged In: YES 
user_id=29957

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 10:03

Message:
Logged In: YES 
user_id=29957




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 18:12:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 18:12:55 2004
Subject: [Patches] [ python-Patches-1001864 ] Logger file objects
Message-ID: 

Patches item #1001864, was opened at 2004-08-02 08:35
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Vinay Sajip (vsajip)
Summary: Logger file objects

Initial Comment:
The logger can return a file like object for each error
level.
These file objects can be sent to any function
expecting a file object.

Example:
>> import logging
>> logging.basicConfig()
>> logger = logging.getLogger()
>> err = logger.getFileObject(logging.ERROR)
>> print >> err, "This is an error"
ERROR:root:This is an error
ERROR:root:

>> err.flush()
>> err.close()


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-08-10 16:12

Message:
Logged In: YES 
user_id=308438

It's also untidy that the blank line is printed. I can
change it so that if the message text is = "\n", it's not
printed.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-08-10 15:49

Message:
Logged In: YES 
user_id=308438

Nice, but I have a question about isatty. Is it needed?
According to the docs for file-like objects, it should not
be implemented unless associated with a real file or device.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-08-09 12:47

Message:
Logged In: YES 
user_id=358087

Hope it works now...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 10:03

Message:
Logged In: YES 
user_id=29957

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 10:03

Message:
Logged In: YES 
user_id=29957




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470
From noreply at sourceforge.net  Tue Aug 10 21:22:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 10 21:22:38 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: Open
Resolution: None
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-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  Wed Aug 11 00:47:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 00:47:53 2004
Subject: [Patches] [ python-Patches-1006916 ] Remove ODBC library references
	from Windows build
Message-ID: 

Patches item #1006916, was opened at 2004-08-11 08:47
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=1006916&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove ODBC library references from Windows build

Initial Comment:
The Windows build files currently reference odbc32.lib
and odbccp32.lib, even though Python doesn't need them.

This patch simply strips out those references from the
affected .vcproj files, which allows building with the
free Microsoft toolkits.

Patch was made from /dist/src.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006916&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 02:10:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 02:11:02 2004
Subject: [Patches] [ python-Patches-1006948 ] Build Patch #941881 (PEP 309
	in C) on windows
Message-ID: 

Patches item #1006948, was opened at 2004-08-11 10: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=1006948&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build Patch #941881 (PEP 309 in C) on windows

Initial Comment:
Patch #941881 provides a C implementation for PEP 309.
This patch allows _that_ patch to be used on Windows.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 02:11:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 02:11:52 2004
Subject: [Patches] [ python-Patches-941881 ] PEP309 Partial implementation
Message-ID: 

Patches item #941881, was opened at 2004-04-26 04:05
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP309 Partial implementation

Initial Comment:
This patch implements functional module which is
introduced by PEP309. It has only 'partial' function as
its member in this stage.

Unittest code is copied and modified slightly from
Patch #931010 by Peter Harris.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 10:11

Message:
Logged In: YES 
user_id=1038590

I have tested this patch on Windows, and it passes its own
test suite, without affecting any other tests.

However, PCBuild\pythoncore.vcproj & PC\config.c require
modification to allow Python to pick up the new module
correctly.

Patch #1006948 created with the needed changes (also removes
unneeded ODBC references from pythoncore.vcproj as I am
using the free MS toolkits to build here)

My patch definitely needs to be checked by someone with a
copy of Vis Studio 2003!

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-08-04 06:23

Message:
Logged In: YES 
user_id=113328

OK, a real need beats my theoretical worries :-) Consider me
convinced.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-05-18 14:05

Message:
Logged In: YES 
user_id=139309

I would use partial in situations where speed can matter (imap, 
commonly used event handlers, etc.), so a fast C implementation would 
be nice to have.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-04-27 18:03

Message:
Logged In: YES 
user_id=113328

Yes, that looks like a significant speed improvement :-) I was 
basing my assumptions on the comments made in the PEP. 
Sorry.

But I still wonder if having the implementation in Python 
wouldn't be better from a maintenance point of view. (As well 
as all the arguments about usefulness as sample code, ability 
to backport, etc etc, that have come up on python-dev 
regarding moving other Python library modules into C...).

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-04-27 12:05

Message:
Logged In: YES 
user_id=55188

Python-version (function) ...   1.19    2.69
Python-version (class) ...      2.61    2.38
C-version ...   0.50    0.37
(former value is for 100000 instanciations and latter is for
100000 calls.)

And, C version have a facility that changing attributes after
the instantiation that is supported by class version only.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-04-27 05:30

Message:
Logged In: YES 
user_id=113328

Why implement this in C? I can't imagine that the
performance improvement will be that significant. A pure
Python module in the standard library seems to me to be a
far better idea. As the PEP says, "the case for a built-in
coded in C is not very strong". And a Python module is good
self-documentation.

I prefer the function version suggested in the PEP (credited
to Carl Banks) over the class-based one. You need to take a
little care to avoid capturing argument names:

    def partial(*args, **kwds):
        def callit(*moreargs, **morekwds):
            kw = kwds.copy()
            kw.update(morekwds)
            return args[0](*(args[1:]+moreargs), **kw)
        return callit

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 02:13:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 02:13:44 2004
Subject: [Patches] [ python-Patches-1006948 ] Build Patch #941881 (PEP 309
	in C) on windows
Message-ID: 

Patches item #1006948, was opened at 2004-08-11 10:10
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build Patch #941881 (PEP 309 in C) on windows

Initial Comment:
Patch #941881 provides a C implementation for PEP 309.
This patch allows _that_ patch to be used on Windows.


----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 10:13

Message:
Logged In: YES 
user_id=1038590

This should be checked by someone with Vis Studio 2003,
since it involves a hand-edited VCPROJ file.

It also has a side effect of removing references to the ODBC
libraries from pythoncore.vcproj (refer Patch #1006916)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006948&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 08:07:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 08:08:24 2004
Subject: [Patches] [ python-Patches-1005857 ] replacing rfc822.formatdate
Message-ID: 

Patches item #1005857, was opened at 2004-08-09 19:31
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005857&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: replacing rfc822.formatdate

Initial Comment:
If we're going to deprecate rfc822, we should stop
using it.
The following patch makes urllib and urllib2 stop using it
for date strings. Unfortunately HTTP insists on the "GMT" 
notation for the timezone, not "-0000"[1], so
email.Utils.formatdate
grew a new flag "asciigmt". 

Assigning to Barry, as email is his baby.


[1]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 16:07

Message:
Logged In: YES 
user_id=1038590

I downloaded and applied this without any apparent problems.

(I got a failure of test_socketserver when running with
-unetwork, but I reverted the patch and confirmed that that
was not due to Anthony's patch)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005857&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 09:20:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 09:20:22 2004
Subject: [Patches] [ python-Patches-1007068 ] baseinteger: abstract
	superclass for int and long
Message-ID: 

Patches item #1007068, was opened at 2004-08-11 11:20
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=1007068&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: baseinteger: abstract superclass for int and long

Initial Comment:
Quote from PEP-237
(http://www.python.org/peps/pep-0237.html):

"""
A new type, integer, may be introduced that is an
abstract base type of which both the int and long
implementation types are subclassed.  This is useful so
that programs can check integer-ness with a single test:

    if isinstance(i, integer): ...
"""

The patch implement the superclass for int and long
with name 'baseinteger'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 10:03:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 10:03:35 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	item joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 18: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=1007087&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: Return new string for single item joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 13:25:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 13:25:30 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 11:25
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=1007189&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 14:52:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 14:52:39 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	item joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 04:03
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&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: Return new string for single item joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-11 08:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 20:22:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 20:22:16 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Wed Aug 11 23:09:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 11 23:09:04 2004
Subject: [Patches] [ python-Patches-1007539 ] Fix for bug #992078
Message-ID: 

Patches item #1007539, was opened at 2004-08-11 16:09
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=1007539&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mitchell Surface (msurface)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug #992078

Initial Comment:
It appears that test__locale was not reseting the locale after its tests. This patch (simplistically) saves and then restores the locale.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 00:17:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 00:17:13 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	item joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 18:03
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&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: Return new string for single item joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 22:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 00:26:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 00:26:47 2004
Subject: [Patches] [ python-Patches-1007539 ] Fix for bug #992078
Message-ID: 

Patches item #1007539, was opened at 2004-08-11 16:09
Message generated for change (Comment added) made by msurface
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mitchell Surface (msurface)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug #992078

Initial Comment:
It appears that test__locale was not reseting the locale after its tests. This patch (simplistically) saves and then restores the locale.

----------------------------------------------------------------------

>Comment By: Mitchell Surface (msurface)
Date: 2004-08-11 17:26

Message:
Logged In: YES 
user_id=21257

The patch was tested against current CVS on Debian GNU/Linux
unstable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 00:52:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 00:52:48 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	item joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 18:03
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&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: Return new string for single item joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 22:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 00:53:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 00:57:02 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	item joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 18:03
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&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: Return new string for single item joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:53

Message:
Logged In: YES 
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 22:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 00:54:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 00:58:12 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	subclass joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 18:03
Message generated for change (Settings changed) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&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: Return new string for single subclass joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:53

Message:
Logged In: YES 
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 22:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 15:09:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 15:09:39 2004
Subject: [Patches] [ python-Patches-1006629 ] Match Solaris def'n of
	_XOPEN_SOURCE
Message-ID: 

Patches item #1006629, was opened at 2004-08-10 17:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006629&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: Match Solaris def'n of _XOPEN_SOURCE

Initial Comment:
Per discussion on python-dev attached is a patch that
causes the _XOPEN_SOURCE definition to match that
defined by G++ on Solaris.  This is the simplest
patch I could come up with.  Perhaps better would be 
to discover the value and use that instead of simply
setting it to 500.  My configure skills weren't up to the
task though.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 15:09

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006629&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:11:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 16:12:07 2004
Subject: [Patches] [ python-Patches-1005891 ] support --with-tsc on PPC
Message-ID: 

Patches item #1005891, was opened at 2004-08-09 12:56
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005891&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Michael Hudson (mwh)
Summary: support --with-tsc on PPC

Initial Comment:
This patch makes the --with-tsc configure option to enable 
low-level profiling of the VM work on PPC (only tested on OS 
X, but should work on linux/ppc too).

Also adds a description of the build to Misc/SpecialBuilds.txt, 
which goes into more detail about the PPC version because I 
know rather more about the PPC architecture than the 
Pentium.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 16:11

Message:
Logged In: YES 
user_id=21627

The patch is fine, please appy. Yes, asm/msr.h is for Linux/x86

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005891&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:16:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 16:16:05 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:43:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 16:43:08 2004
Subject: [Patches] [ python-Patches-1005468 ] Disambiguate "min() or max()"
	exception string
Message-ID: 

Patches item #1005468, was opened at 2004-08-08 13:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005468&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Disambiguate "min() or max()" exception string

Initial Comment:
The min and max builtins are implemented by the same C 
function, and one of the exception strings is:

   ValueError: min() or max() arg is an empty sequence

which is unsurprisingly unhelpful for a statement that calls both of 
them on different sequences. The function knows which operation 
it's implementing it, so why not display the right one?

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 16:43

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as bltinmodule.c 2.317.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005468&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:47:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 16:48:04 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 18:06
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 16:47

Message:
Logged In: YES 
user_id=21627

I notice an inconsistency in the documentation: all
attribute explanations start with a noun explaining the
thing; func_dict starts with "Contains". I'd still like to
see a \versionchanged indicating that the name is only
writable since 2.4.

Apart from that, the patch looks fine.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 18:57

Message:
Logged In: YES 
user_id=6656

OK, take 2.  More documentation, removes the "if (func_name == 
Py_None)" case in func_repr.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-07 15:43

Message:
Logged In: YES 
user_id=21627

These decisions are all fine with me.

As for anonymous functions: It appears that compile.c
2.36/funcobject.c 2.7 introduce the notion of anonymous code
objects (30-Nov-93). compile.c 2.48 (18-Jul-95) takes this
option out again, along with introducing keyword arguments.
So it is probably safe to drop the support for anonymous
functions.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 15:10

Message:
Logged In: YES 
user_id=6656

> Should we require that the new function name is a valid
> identifier?

We could, but I don't really see it being worth the effort
(no attempt is made to ensure that a type's __name__ is a
valid identifier today).

> If not, is an empty string an acceptable function name?

Don't see why not.

> Also, are string subtypes allowed?

Again, don't see why not.

> There should be \versionchanged in the documentation.

Yes.  In fact the documentation of function attributes could
do with being rewritten entirely....

I'll note that all the possibilities you mention are
possiblities today, via new.function.  I'm really not
changing very much.

Agree with Anthony that we don't want to allow unicode.

(While we're at it, I see that func_repr takes into account
that func_name might be Py_None, but I don't think this is
actually possible.  Any ideas?).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-07 12:49

Message:
Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 22:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 20:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:58:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 16:58:43 2004
Subject: [Patches] [ python-Patches-1001604 ] glob doesn't return unicode
	with no dir in unicode filename
Message-ID: 

Patches item #1001604, was opened at 2004-08-01 21:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: leve (leve)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob doesn't return unicode with no dir in unicode filename

Initial Comment:
#Here is the script
#Python 2.3 on W2K
 
import glob
 
name = glob.glob(u"./*.mp3")[0]
print type(name)
name = glob.glob(u"*.mp3")[0]
print type(name)
 
##OUTPUT##
#
#
 
#The second line should be  too.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 16:58

Message:
Logged In: YES 
user_id=21627

The patch in itself is fine - it is policy that file name
functions return Unicode strings for unicode arguments.

The test is flawed, though: there is no guarantee that the
string and the Unicode result compare equal (see
nyamatongwe's message) - there isn't even a guarantee that
they compare without raising an exception.

Also, there is currently no guarantee that
unicode-in-unicode-out works on all platforms. For example,
on Windows 95, this hasn't been implemented (and neither on
OS/2). So I would:

a) drop the test checking for equality
b) consider returns-not-unicode a failure only if os.listdir
does return unicode for unicode arguments.

----------------------------------------------------------------------

Comment By: Neil Hodgson (nyamatongwe)
Date: 2004-08-02 02:09

Message:
Logged In: YES 
user_id=12579

I wrote a slightly different patch that converts the
os.curdir to Unicode inside glob but the patch here is just
as good. The nnorwitz patch works well for me on Windows
with Unicode file names:

>>> glob.glob("*")
['a.bat', 'abc', 'ascii', 'b.bat', 'fileobject.c',
'fileobject.c.diff', 'Gr\xfc\xdf-Gott', 'pep-0277.txt',
'posixmodule.c', 'posixmodule.c.diff', 'uni.py',
'winunichanges.zip', 'Ge??-sa?', '????????????', '??????',
'???', '????G\xdf', '???']

>>> glob.glob(u"*")
[u'a.bat', u'abc', u'ascii', u'b.bat', u'fileobject.c',
u'fileobject.c.diff', u'Gr\xfc\xdf-Gott', u'pep-0277.txt',
u'posixmodule.c', u'posixmodule.c.diff', u'uni.py',
u'winunichanges.zip',
u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2',
u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435',
u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1',
u'\u306b\u307d\u3093',
u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb']

 Here is my patch if you are interested:

--- glob.py     Wed Jun 06 06:24:38 2001
+++ g:\Python23\Lib\glob.py     Sun Aug 01 23:50:43 2004
@@ -19,7 +19,10 @@
             return []
     dirname, basename = os.path.split(pathname)
     if not dirname:
-        return glob1(os.curdir, basename)
+        # Use the current directory but match the argument
+        # string form, either unicode or string.
+        dirname = type(dirname)(os.curdir)
+        return glob1(dirname, basename)
     elif has_magic(dirname):
         list = glob(dirname)
     else:
@@ -40,7 +43,7 @@
     return result

 def glob1(dirname, pattern):
-    if not dirname: dirname = os.curdir
+    assert dirname
     try:
         names = os.listdir(dirname)
     except os.error:

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-08-02 00:31

Message:
Logged In: YES 
user_id=33168

The attached patch fixes the problem and all tests pass on
Linux.  But I'm not really sure if this should be fixed or
not.  Perhaps someone more familiar with unicode and
filenames (like Martin or Marc-Andre?) could provide
feedback.  I don't know if this could create any problems on
Windows.

Changing to a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:53:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 17:02:58 2004
Subject: [Patches] [ python-Patches-1007991 ] @decorators, including classes
Message-ID: 

Patches item #1007991, was opened at 2004-08-12 10:53
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=1007991&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Diederich (jackdied)
Assigned to: Nobody/Anonymous (nobody)
Summary: @decorators, including classes

Initial Comment:
This patch is modeled on the original @ patch #979728

Functions are now ignorant of their decorated status. 
The regular function & class functions are called from
the com_decorated_thing() function which applies the
decorators.  the new Grammar production is 
decorated_thing: decorators (funcdef|classdef)

passes all tests (including augmented test_decorators)

com_decorated_thing() in compile.c uses a VAR_LOAD to
get the class/function to decorate.  There is probably
an easier way to do this.

I updated the compiler package (ast.txt, pycodegen.py,
symbols.py, transformer.py) and it passes all tests but
I'm not sure it is correct (the tests pass as long as
they don't throw an exception).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007991&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 16:08:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 17:03:15 2004
Subject: [Patches] [ python-Patches-1006916 ] Remove ODBC library references
	from Windows build
Message-ID: 

Patches item #1006916, was opened at 2004-08-11 00:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006916&group_id=5470

Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove ODBC library references from Windows build

Initial Comment:
The Windows build files currently reference odbc32.lib
and odbccp32.lib, even though Python doesn't need them.

This patch simply strips out those references from the
affected .vcproj files, which allows building with the
free Microsoft toolkits.

Patch was made from /dist/src.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 16:08

Message:
Logged In: YES 
user_id=21627

Thanks foir the patch. Committed as

_bsddb.vcproj 1.4
_socket.vcproj 1.4
_tkinter.vcproj 1.4
make_versioninfo.vcproj 1.4
pyexpat.vcproj 1.4
python.vcproj 1.4
select.vcproj 1.4


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006916&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 18:27:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 18:27:31 2004
Subject: [Patches] [ python-Patches-995939 ] Avoid calling tp_compare with
	different types
Message-ID: 

Patches item #995939, was opened at 2004-07-22 14:14
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&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: Avoid calling tp_compare with different types

Initial Comment:
C implementations of the tp_compare slot usually expect both of their 
arguments to have the type for which that slot is defined (this isn't 
documented anywhere that I can find, but many core types assume this, 
and extension authors are likely to do the same). A problem occurs if a 
user-defined nb_coerce slot (__coerce__) returns objects with different 
types. Avoid the problem by refusing to call a non-Python tp_compare 
unless the arguments have the same type. Indiscriminately calling 
tp_compare with different types is wrong as long as there are 
implementations that don't check the type of the second argument, but 
Python implementations should be allowed to receive a different type.

Other options for fixing the problem:
  - Make PyNumber_CoerceEx require that the results have the same 
type. This would prevent a user-defined __coerce__ from 
communicating an arbitrary object to a user-defined __cmp__. 
Furthermore, there are uses for coerce besides comparison, and those 
uses might not require identical types.
  - Change tp_compare implementations to check the type of the 
second argument. This might be the most desirable long-term solution, 
but as I understand it, tp_richcompare is preferred over tp_compare for 
new code, and old (current) code is likely assuming that the types are 
the same.

Addresses bug #980352


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2004-08-12 16:27

Message:
Logged In: YES 
user_id=4771

Sorry, I did not read well enough what object.c was doing. 
I agree now that your patch should protect again all
crashes, and that the concern is whether it is too restrictive.

Before rich comparison, there was no obvious sane way to
directly compare objects of different types in C extension
types.  I remember having the problem back in Python 1.5.2;
at the time I solved the problem with an nb_coerce that
returned "fake" objects of a common type, and a tp_compare
that decoded these fake objects.  Now I see that it would
have been simpler to solve the problem by either:

1) writing a nb_coerce that doesn't do anything (but which
is implemented; otherwise tp_compare don't get called at all).
This is what would be broken by the present patch.

2) easier yet, just making sure that both types have the
same tp_compare slot.  We don't need nb_coerce at all in
this case.  The tp_compare would check for the type of both
arguments anyway.  The present patch wouldn't break that.

There is no other reasonable safe way that I can of to fix
the problem (1)...  But admitedly the whole issue is a bit
far-fetched.  So I'd suggest that the issue is deferred
until Python 2.4 is out, and then we put the patch into the
pre-2.5 CVS head.  It's a bit late in the 2.4 release
process to risk breaking potential C extension modules.

A note about the patch: in the first comment you say that v
and w have different types, but that's potentially wrong --
they could have the same type but no tp_compare slot.

The new single test introduced after PyNumber_CoerceEx()
might be too restrictive: it would be enough if v and w have
the same tp_compare slot after coercion.  Pushing things a
bit over the edge of sanity, we might ask "what if coercion
returns old-style instances, or something with
_PyObject_SlotCompare?".  So maybe we should try the whole
try_3way_compare again after coercion (without of course
trying to coerce more than once!).


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-05 09:29

Message:
Logged In: YES 
user_id=908995

The patch is intended to be complete, but it's certainly possible that I 
missed something. Every other call to tp_compare checks that the 
operands have the same type or the same compare function; the only 
exceptions are if one of operands passes PyInstance_Check or if it's 
_PyObject_SlotCompare (it's treated specially in try_3way_compare).

I'm actually more concerned about restricting too much than having 
missing something. The tests I wrote try to make sure that the 
user-visible changes are limited to the absence of a crash, but I'm not 
sure that I didn't accidently break some code that used to work.

Comparing subclasses of builtins to builtins still works, too. On line 599 
of the post-patch object.c, we see:

	/* If both have the same (non-NULL) tp_compare, use it. */
	if (f != NULL && f == w->ob_type->tp_compare) {
		c = (*f)(v, w);
		return adjust_tp_compare(c);
	}

which takes care of that case.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-08-03 09:36

Message:
Logged In: YES 
user_id=4771

Is your patch complete?  There seem to be a lot of places in object.c that call tp_compare slots.  Shouldn't we try to make sure that none of these places can ever be called with two different types?

It also looks like we have to do something special about a value of &_PyObject_SlotCompare in tp_compare, because this function from typeobject.c checks itself the type of its arguments and does specific things with them.  This should be thought about.

Moreover there is the issue of the user subclassing built-in types, e.g. PyInt_Type.tp_compare is capable of comparing different user subclasses of "int" for each other.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995939&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 18:50:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 18:50:12 2004
Subject: [Patches] [ python-Patches-1008086 ] patch for 767150
Message-ID: 

Patches item #1008086, was opened at 2004-08-12 10:50
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=1008086&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mats Wichmann (mwichmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for 767150

Initial Comment:
The attached is a fix for the same problem that is
reported in 767150.  For 2.3.x and head cvs this
problem exists in the code path taken if configure does
not detect inet_aton.  I have not checked this against
2.2, which is the platform 767150 reports it against,
there may be header inclusion issues that make it not
work there but the essence is that the quantity worked
with has to be forced to be a 32-bit quanitity, not
declared unsigned long.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008086&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 19:18:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 19:18:47 2004
Subject: [Patches] [ python-Patches-1007991 ] @decorators, including classes
Message-ID: 

Patches item #1007991, was opened at 2004-08-12 10:53
Message generated for change (Settings changed) made by jackdied
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007991&group_id=5470

>Category: Parser/Compiler
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Diederich (jackdied)
Assigned to: Nobody/Anonymous (nobody)
Summary: @decorators, including classes

Initial Comment:
This patch is modeled on the original @ patch #979728

Functions are now ignorant of their decorated status. 
The regular function & class functions are called from
the com_decorated_thing() function which applies the
decorators.  the new Grammar production is 
decorated_thing: decorators (funcdef|classdef)

passes all tests (including augmented test_decorators)

com_decorated_thing() in compile.c uses a VAR_LOAD to
get the class/function to decorate.  There is probably
an easier way to do this.

I updated the compiler package (ast.txt, pycodegen.py,
symbols.py, transformer.py) and it passes all tests but
I'm not sure it is correct (the tests pass as long as
they don't throw an exception).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007991&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 20:14:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 20:15:03 2004
Subject: [Patches] [ python-Patches-1004703 ] Make func_name writable
Message-ID: 

Patches item #1004703, was opened at 2004-08-06 17:06
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Michael Hudson (mwh)
Summary: Make func_name writable

Initial Comment:
This was pretty easy: just copypasteandchange the code
for func_code :-)  I only allow func_name (or __name__)
to be set to a string.

Adds some simple tests.

I've corrected the one place in the docs that seems to
claim func_name is read only, but the docs for which
function attributes are or aren't read-only don't seem
to be especially accurate already.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-12 19:14

Message:
Logged In: YES 
user_id=6656

Thanks for the review; I've accomodated both your points.

Checked in as:

Doc/lib/libstdtypes.tex revision 1.163
Doc/ref/ref3.tex revision 1.121
Lib/test/test_funcattrs.py revision 1.14
Objects/funcobject.c revision 2.66
Misc/NEWS revision 1.1083

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 15:47

Message:
Logged In: YES 
user_id=21627

I notice an inconsistency in the documentation: all
attribute explanations start with a noun explaining the
thing; func_dict starts with "Contains". I'd still like to
see a \versionchanged indicating that the name is only
writable since 2.4.

Apart from that, the patch looks fine.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 17:57

Message:
Logged In: YES 
user_id=6656

OK, take 2.  More documentation, removes the "if (func_name == 
Py_None)" case in func_repr.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-07 14:43

Message:
Logged In: YES 
user_id=21627

These decisions are all fine with me.

As for anonymous functions: It appears that compile.c
2.36/funcobject.c 2.7 introduce the notion of anonymous code
objects (30-Nov-93). compile.c 2.48 (18-Jul-95) takes this
option out again, along with introducing keyword arguments.
So it is probably safe to drop the support for anonymous
functions.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 14:10

Message:
Logged In: YES 
user_id=6656

> Should we require that the new function name is a valid
> identifier?

We could, but I don't really see it being worth the effort
(no attempt is made to ensure that a type's __name__ is a
valid identifier today).

> If not, is an empty string an acceptable function name?

Don't see why not.

> Also, are string subtypes allowed?

Again, don't see why not.

> There should be \versionchanged in the documentation.

Yes.  In fact the documentation of function attributes could
do with being rewritten entirely....

I'll note that all the possibilities you mention are
possiblities today, via new.function.  I'm really not
changing very much.

Agree with Anthony that we don't want to allow unicode.

(While we're at it, I see that func_repr takes into account
that func_name might be Py_None, but I don't think this is
actually possible.  Any ideas?).

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-07 11:49

Message:
Logged In: YES 
user_id=29957

For instance, allowing a unicode string as a function name
would probably break a truly amazing amount of things.
Tracebacks, pdb, ...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-06 21:44

Message:
Logged In: YES 
user_id=21627

Should we require that the new function name is a valid
identifier? If not, is an empty string an acceptable
function name? Also, are string subtypes allowed?

There should be \versionchanged in the documentation.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-06 19:18

Message:
Logged In: YES 
user_id=44345

Looks good.  Less important in the current context, but for
any of the
attributes which are writable should there be PyFunction_Set
methods
available to help enforce desired behavior (not allowing
non-string
objects for function names for example)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1004703&group_id=5470
From noreply at sourceforge.net  Thu Aug 12 20:20:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 12 20:20:28 2004
Subject: [Patches] [ python-Patches-1005891 ] support --with-tsc on PPC
Message-ID: 

Patches item #1005891, was opened at 2004-08-09 11:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005891&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: support --with-tsc on PPC

Initial Comment:
This patch makes the --with-tsc configure option to enable 
low-level profiling of the VM work on PPC (only tested on OS 
X, but should work on linux/ppc too).

Also adds a description of the build to Misc/SpecialBuilds.txt, 
which goes into more detail about the PPC version because I 
know rather more about the PPC architecture than the 
Pentium.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-12 19:20

Message:
Logged In: YES 
user_id=6656

Thanks for the review.  Checked in as:

Python/ceval.c revision 2.415
Python/sysmodule.c revision 2.126
Misc/SpecialBuilds.txt revision 1.16
Misc/NEWS revision 1.1084

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 15:11

Message:
Logged In: YES 
user_id=21627

The patch is fine, please appy. Yes, asm/msr.h is for Linux/x86

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005891&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 04:57:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 04:57:29 2004
Subject: [Patches] [ python-Patches-1005913 ] Patch to allow building of
	paper-*/dist.pdf
Message-ID: 

Patches item #1005913, was opened at 2004-08-09 07:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005913&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jeff Epler (jepler)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Patch to allow building of paper-*/dist.pdf

Initial Comment:
Building dist.pdf I get a traceback which ends
  File
"/usr/src/cvs-src/python/dist/src/Doc/tools/toc2bkm.py",
line 68, in parse_toc
    direction = _transition_map[(level, stype)]
KeyError: ('section', 'subsubsection')

The error seems to exist because the structure of the
document has
\section{API Reference}
...
\subsubsection{something else}
without an intervening \subsection.  

This patch fixes the problem by making the items under
API reference all \subsection{}s, which may or may not
be what was intended.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-08-12 22:57

Message:
Logged In: YES 
user_id=33168

You're solution works for me.  Thanks!

Checked in as:  dist/dist.tex 1.84

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-09 07:53

Message:
Logged In: YES 
user_id=2772

Oops, I forgot to set the category & group!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005913&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 05:19:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 05:19:28 2004
Subject: [Patches] [ python-Patches-1005778 ] Avoid seg fault if list object
	is modified during list.index
Message-ID: 

Patches item #1005778, was opened at 2004-08-09 01:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005778&group_id=5470

Category: Core (C code)
>Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Avoid seg fault if list object is modified during list.index

Initial Comment:
The list.index implementation can be coerced into indexing past 
the end of ob_item. It calls PyObject_RichCompareBool (which 
may call into Python) in a loop, but the loop counter is only 
checked against a cached copy of the list size, so if the list 
shrinks during the comparison, the next counter value may be out 
of bounds. The patch includes a test case that causes unpatched 
Pythons to seg fault.

I checked the other uses of PyObject_RichCompareBool in 
listobject.c, and all of them look safe (but I mostly glossed over 
the mergesort uses, which I'm sure have been painstakingly 
verified and tested by its author).

(NB: The change to list_tests.py references the revision number of 
the post-patch listobject.c. When this is committed, please make 
sure that, that revision number is still current.)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-08-12 23:19

Message:
Logged In: YES 
user_id=33168

Ouch, good catch.  Thanks!

Checked in as:
 * Objects/listobject.c 2.221
 * Lib/test/list_tests.py 1.3
 * Misc/NEWS 1.1086

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005778&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 10:52:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 10:52:40 2004
Subject: [Patches] [ python-Patches-955928 ] use
	PyOS_ReadlineFunctionPointer in non-interractive input 
Message-ID: 

Patches item #955928, was opened at 2004-05-18 15:41
Message generated for change (Comment added) made by greglielens
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Lielens (greglielens)
>Assigned to: Martin v. L?wis (loewis)
Summary: use PyOS_ReadlineFunctionPointer in non-interractive input 

Initial Comment:
Extend the control provided by
PyOS_ReadlineFunctionPointer to non-interractive
inputs. In addition, initialize
PyOS_ReadlineFunctionPointer to the default input
function, so that it can be retrieved by extern code
(allowing for embedding the old input function and
modifying it). Readline Module changed accordingly
(only modify PyOS_ReadlineFunctionPointer to
call_readline if input is interractive).
This was neccessary to modify the input behavior of
PyRun_InteractiveLoop, in case input is not interractive...
The application is a python driven parallel framework
using MPI, where the interractive process broadcast the
input lines to the non-interractive processes, who
listen...but other applications may benefit also.
patched: Modules/readline.c
               Parser/myreadline.c

----------------------------------------------------------------------

>Comment By: Gregory Lielens (greglielens)
Date: 2004-08-13 10:52

Message:
Logged In: YES 
user_id=1044428

Hi,
as you are the last one which has worked on this subject, I
think it is best I reassign this patch to you. As you will
see from my discussion with mwh, the main  point of these
modif is to remove the test of the interractiveness of
stdin/stdout that prevent the use of
PyOS_ReadlineFunctionPointer when one is not interactive...

Hope this re-assignment is not rude, I do not know well
python development group usage in this matter...

Best regards, Greg

----------------------------------------------------------------------

Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 14:02

Message:
Logged In: YES 
user_id=1044428

I edited the patch to comply with the tab style (or hope so).
For the reverse, I used cvs diff -c and assumed it would
produce it in the correct order, is it not the case? Anyway,
here is the new patch... (If it is still reversed and you
have a special option for cvs diff to produce the patch in
correct order, I am very interrested! ;-) )

Regarding the origin of the tty test, it is done (at least
for the stdin) since the first revision that used a
mechanism similar to the current one
(PyOS_ReadlineFunctionPointer), and this was done by Guido
(r2.11)
The test was removed just after (r2.12, again guido),
and finally re-introduced in it's final form in revision
2.28, by loewis.
Maybe I can assign him so that he gives us a idea of the
intention of this, and his feeling about this patch?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 13:21

Message:
Logged In: YES 
user_id=6656

Uh, no, scratch that: I think your attempt to upload a new
patch failed.  Try again?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 13:11

Message:
Logged In: YES 
user_id=6656

A chance, yes.  I'm a bit loath to change this, as I have no
idea why things were done this way in the first place.  If
it's the traditional "no good reason", then I guess this can
go in...

Also, I think your patch is backwards and doesn't adhere to
the local style wrt tabs and spaces.

----------------------------------------------------------------------

Comment By: Gregory Lielens (greglielens)
Date: 2004-08-05 09:56

Message:
Logged In: YES 
user_id=1044428

I updated the patch to python current CVS, and do similar
modification in /Python/bltinmodule.c for builtin_raw_input
fonction.
builtin_raw_input now call PyOS_Readline when  stdin and
stdout objects are file, regardless if they are tty or not.
This one was forgotten in the first version of the patch,
and is needed to be able to use the same broadcasting
technique for parrallel interractive session when using
IPython. I now think that all functions implementing
possibly interractive input have been patched...
All regression tests pass except test_grp and test_pwd, but
those fail exactly the same way (KeyError) with non-patched
cvs...
Any chance to have this considered for 2.4?
Regards,
Greg.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=955928&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 11:07:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 11:07:54 2004
Subject: [Patches] [ python-Patches-1008588 ] Let test__locale save locale
	(bug #992078)
Message-ID: 

Patches item #1008588, was opened at 2004-08-13 11: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=1008588&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Let test__locale save locale (bug #992078)

Initial Comment:
test__locale is not resetting the locale after running
the tests. This patch saves and then restores the old
locale. It is mostly similar to
http://python.org/sf/1007539: : I just wrapped the
block from 'saw_locale' to 'raise ImportError' in a
try: finally: block and used LC_NUMERIC instead of LC_ALL.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 11:08:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 11:08:25 2004
Subject: [Patches] [ python-Patches-1007539 ] Fix for bug #992078
Message-ID: 

Patches item #1007539, was opened at 2004-08-11 23:09
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mitchell Surface (msurface)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug #992078

Initial Comment:
It appears that test__locale was not reseting the locale after its tests. This patch (simplistically) saves and then restores the locale.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 11:08

Message:
Logged In: YES 
user_id=469548

I was just working on the same bug yesterday. I produced a
mostly similar patch: I just wrapped the block from
'saw_locale' to 'raise ImportError' in a try: finally: block
and used LC_NUMERIC instead of LC_ALL. See
http://python.org/sf/1008588.

----------------------------------------------------------------------

Comment By: Mitchell Surface (msurface)
Date: 2004-08-12 00:26

Message:
Logged In: YES 
user_id=21257

The patch was tested against current CVS on Debian GNU/Linux
unstable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 11:30:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 11:30:16 2004
Subject: [Patches] [ python-Patches-573197 ] cgi.py and rfc822.py unquote
	fixes
Message-ID: 

Patches item #573197, was opened at 2002-06-24 18:21
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=573197&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 4
Submitted By: Quinn Dunkan (quinn_dunkan)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: cgi.py and rfc822.py unquote fixes

Initial Comment:
This makes cgi.parse_header() properly unquote header
parameters.  E.g.,
given a header:

content-disposition: attachment;
filename="weird\file\"name"

parse_header() should return ('attachment',
{'filename': 'weird\file"name'}),
but the current parse_header() just strips the ""s, it
doesn't unquote the \s,
so you get too many \s in the output.

This could possibly use rfc822.unquote, but
rfc822.unquote doesn't unquote \s
either!  This looks like a bug since immediately
preceeding the definition of
rfc822.unquote is

# XXX Should fix unquote() and quote() to be really
conformant. 


The email package uses rfc822.unquote, which means its
msg.get_filename()
has the "too many \s" problem.  So maybe I'll include a
patch for rfc822.py as
well, and send a patch to Barry for email/Util.py.

A quick glance through RFC 822 sheds no light on the
use of <> for quoted
*strings*, only for addr-spec.  So I'm not sure what
kind of quoting goes in
in them, and "none" seems a reasonable guess, so I
didn't change it.

So does that make unquote() "really conformant"?  Dunno...

I've got this feeling like rfc822.py is sort of
supposed to be subsumed by the
email package anyway...


Oh, and according to the RFC, the other thing not
allowed in ""s
is newline, but I wasn't sure if that was quoted with a
\.  If so, that's
an easy fix.  I have a feeling newlines in quoted
strings aren't a
great idea anyway since, even if legal, many simple parsers
will probably not like them.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 11:30

Message:
Logged In: YES 
user_id=469548

rfc822 and email have been fixed a while ago, but
cgi.parse_header() still needs to be fixed. I've submitted a
less intrusive patch at http://python.org/sf/1008597.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=573197&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 11:30:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 11:30:44 2004
Subject: [Patches] [ python-Patches-1008588 ] Let test__locale save locale
	(bug #992078)
Message-ID: 

Patches item #1008588, was opened at 2004-08-13 11:07
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470

>Category: Tests
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Let test__locale save locale (bug #992078)

Initial Comment:
test__locale is not resetting the locale after running
the tests. This patch saves and then restores the old
locale. It is mostly similar to
http://python.org/sf/1007539: : I just wrapped the
block from 'saw_locale' to 'raise ImportError' in a
try: finally: block and used LC_NUMERIC instead of LC_ALL.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 15:49:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 15:49:17 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From erica55 at bol.com.br  Fri Aug 13 16:34:41 2004
From: erica55 at bol.com.br (Erica Silveira)
Date: Fri Aug 13 16:34:34 2004
Subject: [Patches] Mala direta por e-mail - As melhores listas de email
Message-ID: <20040813143433.28F661E4384@bag.python.org>

Mala direta por e-mail. Cadastros selecionados. As melhores listas 
de e-mails selecionados por estados, atividades e profiss?es.
Listas atualizadas para mala direta via e-mail marketing. Visite

http://www.promonet.mx.gs

Cadastros altamente selecionados para divulga??o de produtos por
email marketing. Listas de e-mails e programas gr?tis para divulga??o
via correio eletr?nico. Mala direta por e-mail. Visite agora:

http://www.promonet.mx.gs
From noreply at sourceforge.net  Fri Aug 13 16:43:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 16:43:18 2004
Subject: [Patches] [ python-Patches-1007068 ] baseinteger: abstract
	superclass for int and long
Message-ID: 

Patches item #1007068, was opened at 2004-08-11 03:20
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: baseinteger: abstract superclass for int and long

Initial Comment:
Quote from PEP-237
(http://www.python.org/peps/pep-0237.html):

"""
A new type, integer, may be introduced that is an
abstract base type of which both the int and long
implementation types are subclassed.  This is useful so
that programs can check integer-ness with a single test:

    if isinstance(i, integer): ...
"""

The patch implement the superclass for int and long
with name 'baseinteger'.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-13 10:43

Message:
Logged In: YES 
user_id=6380

+1

One suggestion: I'd add some words to the docs to recommend
*not* to use this for one's own integer-ish class. Instead,
subclassing from int or long is recommended, to avoid
confusion (since many built-in operations and extensions
accept only "genuine" integers, i.e. int or long or
subclasses thereof).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 16:56:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 16:56:36 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 07:25
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-13 10:56

Message:
Logged In: YES 
user_id=6380

+1 from a quick glance.

Missing a Misc/NEWS file update.

Suggestion: add "from sys import (*)" to the fail tests.

Please ask Fred to review the parser module changes.

Please ask Jeremy to review the compiler module changes.

Shouldn't there be more docs? Tutorial examples? Etc.

All that can be done after it's checked in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 17:13:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 17:13:31 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-05 01:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 17:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 17:36:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 17:46:13 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 11:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 09:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 01:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-06 00:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 10:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 08:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 01:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 00:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 16:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 15:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 18:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 18:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 20:19:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 20:19:58 2004
Subject: [Patches] [ python-Patches-982681 ]
	asyncore.dispatcher.set_reuse_addr() is broken on windows
Message-ID: 

Patches item #982681, was opened at 2004-06-30 07:14
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Garth Bushell (garth42)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore.dispatcher.set_reuse_addr() is broken on windows

Initial Comment:
asyncore.dispatcher.set_reuse_addr()  uses
socket.SO_REUSEADDR to allow reuse of same address
without having to wait. 

On windows this also allows multiple programs to bind
to the same socket adress. What is probably needed is
to use  SO_EXCLUSIVEADDRUSE on windows which has the
same meaning as SO_REUSEADDR on all other platforms. 

This will stop people running the server multiple times
and getting wierd results or two programs sharing the
same port without realising.





----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-13 14:19

Message:
Logged In: YES 
user_id=11375

SO_EXCLUSIVEADDRUSE actually has quite different semantics
from what SO_REUSEADDR is intended to be; backing out this
change.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 11:52

Message:
Logged In: YES 
user_id=11375

Checked into CVS; thanks.



----------------------------------------------------------------------

Comment By: Garth Bushell (garth42)
Date: 2004-06-30 07:14

Message:
Logged In: YES 
user_id=45280

this depends on patch #982665

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 21:00:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 21:00:48 2004
Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4
	implementation
Message-ID: 

Patches item #1000267, was opened at 2004-07-29 13:52
Message generated for change (Comment added) made by cjschr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: chads (cjschr)
Assigned to: Nobody/Anonymous (nobody)
Summary: A BSD-style wait4 implementation

Initial Comment:
A BSD-style wait4 implementation.

Using existing code from the posixmodule.c and
resource.c files,
I threw together a patch that implements the wait4
function.

This function is similar to waitpid, but it also
returns usage information
about the child process.

wait4(pid, options) -> (pid, status, rusage)

It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes
using
Python-2.3.4.

The patch may need some fine tuning.

Thanks
Chad

----------------------------------------------------------------------

>Comment By: chads (cjschr)
Date: 2004-08-13 14:00

Message:
Logged In: YES 
user_id=1093928

Added a test suite and an example of using wait4.  Feedback
is welcome.
Thanks.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-04 16:53

Message:
Logged In: YES 
user_id=2772

You should also add code to the test suite to test wait4
when it is available.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470
From noreply at sourceforge.net  Fri Aug 13 21:24:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 13 21:24:36 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-04 16:23
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2004-08-13 12:24

Message:
Logged In: YES 
user_id=971153


>- The checkline() docstring needs to be updated.
>- Try not to use multi-line comments after a statement
>(e.g.: 'return False #it's not a func call, but rather', etc.).

Ok, I can resubmit a patch for these two


>- For consistency, Breakpoint.breakingline should probably
>be called func_firstlineno.

Well, I am not sure: func_firstlineno causes a wrong
association with
co_firstlineno (while these are almost never the same).
Furthermore,
the  name ".breakingline" reflects the purpose: "a line
number where to break", while, "func_firstlineno" is totatly
neutral..
 

>- Moving the 'bp.breakingline=frame.f_lineno' statement into
>an else: branch of the 'if bp.breakingline and
>(bp.breakingline != frame.f_lineno)' statement would
>probably make the logic clearer.

Are you suggesting to replace:

                if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
                bp.breakingline=frame.f_lineno

with:

               if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
               else: 
                    bp.breakingline=frame.f_lineno

Why do you think it's better? It's definitely more verbose, has
an extra indentation level and looking through the code I
see a lot of code which looks like:

if  (....):
    return
foo
bar
without the else: branch


Would the following be better?

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 

Thus making it explicit that there are really 2 decisions
being made:
1) do we need to set the breakingline
2) do we need to break here


I don't have any strong feelings regarding these 2 issues,
just want to make sure that I understand the problem





----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 08:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 00:47:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 00:47:30 2004
Subject: [Patches] [ python-Patches-982681 ]
	asyncore.dispatcher.set_reuse_addr() is broken on windows
Message-ID: 

Patches item #982681, was opened at 2004-06-30 07:14
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Garth Bushell (garth42)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore.dispatcher.set_reuse_addr() is broken on windows

Initial Comment:
asyncore.dispatcher.set_reuse_addr()  uses
socket.SO_REUSEADDR to allow reuse of same address
without having to wait. 

On windows this also allows multiple programs to bind
to the same socket adress. What is probably needed is
to use  SO_EXCLUSIVEADDRUSE on windows which has the
same meaning as SO_REUSEADDR on all other platforms. 

This will stop people running the server multiple times
and getting wierd results or two programs sharing the
same port without realising.





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-13 18:47

Message:
Logged In: YES 
user_id=31435

Noting that the patch broke the test suite for ZEO (Zope's 
networked-database layer on top of ZODB) on Windows.  
That all worked again after Andrew backed out the patch.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-13 14:19

Message:
Logged In: YES 
user_id=11375

SO_EXCLUSIVEADDRUSE actually has quite different semantics
from what SO_REUSEADDR is intended to be; backing out this
change.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 11:52

Message:
Logged In: YES 
user_id=11375

Checked into CVS; thanks.



----------------------------------------------------------------------

Comment By: Garth Bushell (garth42)
Date: 2004-06-30 07:14

Message:
Logged In: YES 
user_id=45280

this depends on patch #982665

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=982681&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 06:48:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 06:48:52 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 (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009075&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009075&group_id=5470
From evesiz at seznam.cz  Mon Aug 16 03:15:39 2004
From: evesiz at seznam.cz (Helaven Uenasaw)
Date: Sat Aug 14 07:09:02 2004
Subject: [Patches] Customers support. Last releases update. discount_=
Message-ID: <20040814050901.B3C011E4002@bag.python.org>

Dear clients.
We have update our catalogue, 
now we have more and new version 
prog.rams. 
Our full catalogue with 1400 fresh 
and unique so.ftw.are titles.
Id: eisl

http://un.eiqn.com/1/p/?discountid=haru

With regards, 
floigsn Customers Manager 
Helyben Utebr.
From noreply at sourceforge.net  Sat Aug 14 08:15:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 08:15:13 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 docwatson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009075&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
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: 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  Sat Aug 14 12:04:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 12:04:55 2004
Subject: [Patches] [ python-Patches-1008588 ] Let test__locale save locale
	(bug #992078)
Message-ID: 

Patches item #1008588, was opened at 2004-08-13 11:07
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Let test__locale save locale (bug #992078)

Initial Comment:
test__locale is not resetting the locale after running
the tests. This patch saves and then restores the old
locale. It is mostly similar to
http://python.org/sf/1007539: : I just wrapped the
block from 'saw_locale' to 'raise ImportError' in a
try: finally: block and used LC_NUMERIC instead of LC_ALL.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-14 12:04

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 12:14:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 12:14:50 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 11:25
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-14 10:14

Message:
Logged In: YES 
user_id=908995

Uploaded new patch. Changes:

  - Support trailing comma in from list (suggested by Michael
    Chermside on python-dev). This form is now acceptable:

      from os import (path,)

    but this is not:

      from os import path,

    I originally wanted to support the latter for consistency, but I
    don't think it's necessary (who would want to do that but not use
    parens?) and it's potentially confusing in a case like this:

      from sys import stdin,
      stdout

    which looks like it was intended to be one statement, but the
    second line is actually separate. The way the grammar is written,
    the case with a trailing comma but no parentheses parses okay, but
    it is intentionally rejected by the compiler.

  - Added more success and fail cases, incl. the "import (*)" case.

  - Added NEWS entry. (I'm uncertain whether providing this as part of
    a larger change actually helps; the file changes often enough that
    the patch stands a good chance of not applying cleanly.)

There should definitely be more docs, but I intentionally didn't try
to include unnecessary changes in this patch. As already mentioned,
that can be done later.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-13 14:56

Message:
Logged In: YES 
user_id=6380

+1 from a quick glance.

Missing a Misc/NEWS file update.

Suggestion: add "from sys import (*)" to the fail tests.

Please ask Fred to review the parser module changes.

Please ask Jeremy to review the compiler module changes.

Shouldn't there be more docs? Tutorial examples? Etc.

All that can be done after it's checked in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 12:31:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 12:31:12 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 ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009075&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
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: 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  Sat Aug 14 12:40:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 12:40:37 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-05 01:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 12:40

Message:
Logged In: YES 
user_id=469548

"Well, I am not sure: func_firstlineno causes a wrong
association with co_firstlineno (while these are almost
never the same)."

Ah, I misread the patch there. How about
func_first_executable_lineno (or something like that)? Or am
I off-base again?

"Would the following be better?"

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 
"

Yes. I was just having a bit of a hard time following your
patch. I think this is clearer.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-13 21:24

Message:
Logged In: YES 
user_id=971153


>- The checkline() docstring needs to be updated.
>- Try not to use multi-line comments after a statement
>(e.g.: 'return False #it's not a func call, but rather', etc.).

Ok, I can resubmit a patch for these two


>- For consistency, Breakpoint.breakingline should probably
>be called func_firstlineno.

Well, I am not sure: func_firstlineno causes a wrong
association with
co_firstlineno (while these are almost never the same).
Furthermore,
the  name ".breakingline" reflects the purpose: "a line
number where to break", while, "func_firstlineno" is totatly
neutral..
 

>- Moving the 'bp.breakingline=frame.f_lineno' statement into
>an else: branch of the 'if bp.breakingline and
>(bp.breakingline != frame.f_lineno)' statement would
>probably make the logic clearer.

Are you suggesting to replace:

                if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
                bp.breakingline=frame.f_lineno

with:

               if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
               else: 
                    bp.breakingline=frame.f_lineno

Why do you think it's better? It's definitely more verbose, has
an extra indentation level and looking through the code I
see a lot of code which looks like:

if  (....):
    return
foo
bar
without the else: branch


Would the following be better?

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 

Thus making it explicit that there are really 2 decisions
being made:
1) do we need to set the breakingline
2) do we need to break here


I don't have any strong feelings regarding these 2 issues,
just want to make sure that I understand the problem





----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 17:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 12:58:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 12:58:33 2004
Subject: [Patches] [ python-Patches-1008588 ] Let test__locale save locale
	(bug #992078)
Message-ID: 

Patches item #1008588, was opened at 2004-08-13 11:07
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470

Category: Tests
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Let test__locale save locale (bug #992078)

Initial Comment:
test__locale is not resetting the locale after running
the tests. This patch saves and then restores the old
locale. It is mostly similar to
http://python.org/sf/1007539: : I just wrapped the
block from 'saw_locale' to 'raise ImportError' in a
try: finally: block and used LC_NUMERIC instead of LC_ALL.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 12:58

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.5 for test__locale__.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-14 12:04

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008588&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 12:59:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 12:59:08 2004
Subject: [Patches] [ python-Patches-1007539 ] Fix for bug #992078
Message-ID: 

Patches item #1007539, was opened at 2004-08-11 23:09
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470

Category: Tests
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mitchell Surface (msurface)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug #992078

Initial Comment:
It appears that test__locale was not reseting the locale after its tests. This patch (simplistically) saves and then restores the locale.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 12:59

Message:
Logged In: YES 
user_id=469548

Checked in with my modifications as rev 1.5.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 11:08

Message:
Logged In: YES 
user_id=469548

I was just working on the same bug yesterday. I produced a
mostly similar patch: I just wrapped the block from
'saw_locale' to 'raise ImportError' in a try: finally: block
and used LC_NUMERIC instead of LC_ALL. See
http://python.org/sf/1008588.

----------------------------------------------------------------------

Comment By: Mitchell Surface (msurface)
Date: 2004-08-12 00:26

Message:
Logged In: YES 
user_id=21257

The patch was tested against current CVS on Debian GNU/Linux
unstable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007539&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 13:33:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 13:33:31 2004
Subject: [Patches] [ python-Patches-548197 ] Adds cookie support to
	urllib2.py
Message-ID: 

Patches item #548197, was opened at 2002-04-24 18:31
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=548197&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Jeff Pitman (bruthasj)
Assigned to: Jeremy Hylton (jhylton)
Summary: Adds cookie support to urllib2.py

Initial Comment:
Problem    
   
Whenever urllib2 encounters a complex sequence of redirects   
and authentication schemes it is extremely difficult to   
"inject" Cookie headers to each request.   
   
Solution   
   
Make a small change to AbstractHTTPHandler that will detect on   
a host-by-host basis if there are any stored cookies.  This is   
done by using a Dict that is initialized on import of urllib2.    
Therefore the Dict of Hosts is available throughout multiple   
instances of request objects and multiple urlopens on those   
objects.     
   
Upon detection, it will send the Cookies along with the other   
request headers to the host.  If there isn't any, it just   
skips it.    
   
The next thing is to collect the Cookies when we get the   
"reply" from the host.  All of this is done within   
AbstractHTTPHandler -- no other modifications required.   
  
Test  
  
I can login into http://mantisbt.sf.net/ which requires the  
browser to maintain a set of cookies during the session.  
  
   
Future   
   
* Maybe use external files to store and control storage of   
cookies   
* Better API in Cookie module so we don't have to do the 
string.split hack   
* Better API in urllib2 for Cookies (or just make it 
transparent? or both?) 
   
   

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 13:33

Message:
Logged In: YES 
user_id=469548

Closing as outdated.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-06-03 00:41

Message:
Logged In: YES 
user_id=261020

This should be closed, since it's obsoleted by the new
module cookielib (patch 963318).

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-12-09 21:50

Message:
Logged In: YES 
user_id=261020

I just noticed the thread on c.l.py about this, rather late... a day
before that thread started (great minds think alike, apparently),
I released the first version of this:

http://wwwsearch.sourceforge.net/ClientCookie

I intend eventually to get it into a fit state for inclusion in Python.
It's certainly not there yet, but it does work, and is integrated
with urllib2.


----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 13:22

Message:
Logged In: YES 
user_id=11645

You're giving no control at all to the Python user over
cookies. Additionally, doing it on a per-import
basis is wrong: what if there are two non-co-operating
modules each using urllib2 for their own purposes?. 
I suggest writing a Cookie mixin which people can mixin to
their classes
when they create a manager, which will keep a list of
cookies and so on.

Thanks.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-30 20:20

Message:
Logged In: YES 
user_id=80475

I think this looks good.

Please resubmit patch using the latest version of 
urllib2.py and using string methods instead of the (about 
to be deprecated) string module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=548197&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 15:31:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 15:31:51 2004
Subject: [Patches] [ python-Patches-854853 ] shutil.copyfile destroys hard
	links (Bug [ 851123 ])
Message-ID: 

Patches item #854853, was opened at 2003-12-05 17:33
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.copyfile destroys hard links (Bug [ 851123 ])

Initial Comment:
shutil.copyfile(src,dst) will destroy src if dst is a
hard or symbolic link to src.  (This is bug [851123].)

There was a version of patch [ 604600 ] For Bug [
490168 ] which sought to address this problem but it
wasn't implemented properly.

My patch checks for the existence of
os.path.samefile(), (which on posix systems follows
symlinks) and uses that as a guard if available.  It
catches the exception raised by samefile() if dst does
not exist.  (It also catches the exception raised if
src does not exist, but this doesn't matter since that
condition will cause a new exception in the next part
of the code.)

I have included test code, which tests for the bug only
if os.symlink exists.  If there is a platform with
symlink but not samefile, the test will fail; I think
that would indicate more fixing of shutil.py is required.
I avoided using tempfile.mktemp to a degree since that
function is now deprecated.  I made a judgement call
that calling mktemp with a private temp dir (from
mkdtemp) is safe. Perhaps in a private temp dir we can
just use a hard-coded filename, if mktemp is really
despised.

Since this is just a bugfix I included no doc updates.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 15:31

Message:
Logged In: YES 
user_id=469548

Checked in your revised patch as rev 1.31 of shutil.py and
rev 1.5 of test_shutil.py, with some modifications (notably,
not using a blank except: statement and using
test_support.TESTFN),

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2004-07-14 21:11

Message:
Logged In: YES 
user_id=11365

I've revised the patch to make the test code more consistent
with what was already present.  I think this should be
accepted or rejected before python2.4 ships, as it is a good
complement to 
Bug #919012.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 16:06:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 16:06:03 2004
Subject: [Patches] [ python-Patches-854853 ] shutil.copyfile destroys hard
	links (Bug [ 851123 ])
Message-ID: 

Patches item #854853, was opened at 2003-12-05 17:33
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: shutil.copyfile destroys hard links (Bug [ 851123 ])

Initial Comment:
shutil.copyfile(src,dst) will destroy src if dst is a
hard or symbolic link to src.  (This is bug [851123].)

There was a version of patch [ 604600 ] For Bug [
490168 ] which sought to address this problem but it
wasn't implemented properly.

My patch checks for the existence of
os.path.samefile(), (which on posix systems follows
symlinks) and uses that as a guard if available.  It
catches the exception raised by samefile() if dst does
not exist.  (It also catches the exception raised if
src does not exist, but this doesn't matter since that
condition will cause a new exception in the next part
of the code.)

I have included test code, which tests for the bug only
if os.symlink exists.  If there is a platform with
symlink but not samefile, the test will fail; I think
that would indicate more fixing of shutil.py is required.
I avoided using tempfile.mktemp to a degree since that
function is now deprecated.  I made a judgement call
that calling mktemp with a private temp dir (from
mkdtemp) is safe. Perhaps in a private temp dir we can
just use a hard-coded filename, if mktemp is really
despised.

Since this is just a bugfix I included no doc updates.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 15:31

Message:
Logged In: YES 
user_id=469548

Checked in your revised patch as rev 1.31 of shutil.py and
rev 1.5 of test_shutil.py, with some modifications (notably,
not using a blank except: statement and using
test_support.TESTFN),

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2004-07-14 21:11

Message:
Logged In: YES 
user_id=11365

I've revised the patch to make the test code more consistent
with what was already present.  I think this should be
accepted or rejected before python2.4 ships, as it is a good
complement to 
Bug #919012.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 16:52:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 16:52:48 2004
Subject: [Patches] [ python-Patches-996627 ] realpath: resolve symlinks
	before normalizing (bug #990669)
Message-ID: 

Patches item #996627, was opened at 2004-07-23 17:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: realpath: resolve symlinks before normalizing (bug #990669)

Initial Comment:
This patch fixes the problem described in
http://python.org/sf/990669 and adds tests for realpath.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 16:52

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.39 of libposixpath.tex.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 16:58:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 16:58:13 2004
Subject: [Patches] [ python-Patches-996626 ] normpath symlinks doc warning
	(bug #990669)
Message-ID: 

Patches item #996626, was opened at 2004-07-23 17:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996626&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: normpath symlinks doc warning (bug #990669)

Initial Comment:
normpath may alter the meaning of a path if it contains
symbolic links. This has been documented in a comment
since 1992, but it should be in the library reference
as well.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 16:58

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.39 of libposixpath.tex.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 18:05

Message:
Logged In: YES 
user_id=6656

 

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996626&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 17:02:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 17:02:20 2004
Subject: [Patches] [ python-Patches-996627 ] realpath: resolve symlinks
	before normalizing (bug #990669)
Message-ID: 

Patches item #996627, was opened at 2004-07-23 17:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470

Category: Library (Lib)
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: realpath: resolve symlinks before normalizing (bug #990669)

Initial Comment:
This patch fixes the problem described in
http://python.org/sf/990669 and adds tests for realpath.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 17:02

Message:
Logged In: YES 
user_id=469548

Heh, wrong bug: this was actually checked in as rev 1.71 of
posixpath.py and rev 1.10 of test_posixpath.py.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 16:52

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.39 of libposixpath.tex.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=996627&group_id=5470
From noreply at sourceforge.net  Sat Aug 14 17:41:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 14 17:41:20 2004
Subject: [Patches] [ python-Patches-573197 ] cgi.py and rfc822.py unquote
	fixes
Message-ID: 

Patches item #573197, was opened at 2002-06-24 18:21
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=573197&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Quinn Dunkan (quinn_dunkan)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: cgi.py and rfc822.py unquote fixes

Initial Comment:
This makes cgi.parse_header() properly unquote header
parameters.  E.g.,
given a header:

content-disposition: attachment;
filename="weird\file\"name"

parse_header() should return ('attachment',
{'filename': 'weird\file"name'}),
but the current parse_header() just strips the ""s, it
doesn't unquote the \s,
so you get too many \s in the output.

This could possibly use rfc822.unquote, but
rfc822.unquote doesn't unquote \s
either!  This looks like a bug since immediately
preceeding the definition of
rfc822.unquote is

# XXX Should fix unquote() and quote() to be really
conformant. 


The email package uses rfc822.unquote, which means its
msg.get_filename()
has the "too many \s" problem.  So maybe I'll include a
patch for rfc822.py as
well, and send a patch to Barry for email/Util.py.

A quick glance through RFC 822 sheds no light on the
use of <> for quoted
*strings*, only for addr-spec.  So I'm not sure what
kind of quoting goes in
in them, and "none" seems a reasonable guess, so I
didn't change it.

So does that make unquote() "really conformant"?  Dunno...

I've got this feeling like rfc822.py is sort of
supposed to be subsumed by the
email package anyway...


Oh, and according to the RFC, the other thing not
allowed in ""s
is newline, but I wasn't sure if that was quoted with a
\.  If so, that's
an easy fix.  I have a feeling newlines in quoted
strings aren't a
great idea anyway since, even if legal, many simple parsers
will probably not like them.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 17:41

Message:
Logged In: YES 
user_id=469548

cgi.parse_header() has now been fixed as well (rev 1.80).
Thanks for the report!

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 11:30

Message:
Logged In: YES 
user_id=469548

rfc822 and email have been fixed a while ago, but
cgi.parse_header() still needs to be fixed. I've submitted a
less intrusive patch at http://python.org/sf/1008597.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=573197&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 01:57:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 01:57:51 2004
Subject: [Patches] [ python-Patches-1009373 ] (bug 1005936) textunderscore
	python.sty fix
Message-ID: 

Patches item #1009373, was opened at 2004-08-14 23:57
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=1009373&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Watson (docwatson)
Assigned to: Nobody/Anonymous (nobody)
Summary: (bug 1005936) textunderscore python.sty fix

Initial Comment:
(bug 1005936)

In pdf bookmark links, \_ was being converted to
'protect hbox.....55ex', instead of being inserted
verbatim.   This fix, taken from hyperref, changes \_
to {\string_} so that it is output correctly in the
bookmarks file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009373&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 03:12:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 03:12:33 2004
Subject: [Patches] [ python-Patches-1009384 ] Docstring fix in Modules/_csv.c
Message-ID: 

Patches item #1009384, was opened at 2004-08-15 04: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=1009384&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docstring fix in Modules/_csv.c

Initial Comment:
The ``\r\n`` in a docstring weren't quoted, resulting
in a newline, which was not intended.

Used the occasion to also remove random indentation a
few lines below.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009384&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 03:35:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 03:35:45 2004
Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode
	__credits__ in Lib/pydoc.py
Message-ID: 

Patches item #1009389, was opened at 2004-08-15 04: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=1009389&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py

Initial Comment:
There are non-ASCII chars in pydoc.__credits__ (the
"o/" in "Mynd you, mo/o/se bites Kan be pretty
nasti...").  In 2.3, a locale declaration of Latin-1
was added to pydoc.py.  So now Python does not complain
-- but a string object (carrying no encoding info) with
Latin-1 bytes is still created and anynoby running in a
non-Latin-1 locale will not interpret the string correctly.
The patch fixes it by making pydoc.__credits__ a
Unicode string.  *Note that this may break code* that
prints pydoc.__credits__ (in locales that can't encode
it) or otherwise assumes it's a string.  Not that such
code exists anywhere...
Wait, ``import pydoc; help(pydoc)`` in "C" locale now
crashes !  This is too ironic, IMHO, *don't
commit* until pydoc learns to handle unicode robustly...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 03:57:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 03:57:15 2004
Subject: [Patches] [ python-Patches-1009373 ] (bug 1005936) textunderscore
	python.sty fix
Message-ID: 

Patches item #1009373, was opened at 2004-08-14 18:57
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009373&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Watson (docwatson)
Assigned to: Nobody/Anonymous (nobody)
Summary: (bug 1005936) textunderscore python.sty fix

Initial Comment:
(bug 1005936)

In pdf bookmark links, \_ was being converted to
'protect hbox.....55ex', instead of being inserted
verbatim.   This fix, taken from hyperref, changes \_
to {\string_} so that it is output correctly in the
bookmarks file.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-14 20:57

Message:
Logged In: YES 
user_id=2772

This works for me.  I rebuilt html and pdf versions of the
documentation, and everything looked fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009373&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 05:30:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 05:30:40 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-04 16:23
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2004-08-14 20:30

Message:
Logged In: YES 
user_id=971153

Ok, I'll submit an updated patch hopefully by the end of the
next week (I will be out of town for the next few days).

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 03:40

Message:
Logged In: YES 
user_id=469548

"Well, I am not sure: func_firstlineno causes a wrong
association with co_firstlineno (while these are almost
never the same)."

Ah, I misread the patch there. How about
func_first_executable_lineno (or something like that)? Or am
I off-base again?

"Would the following be better?"

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 
"

Yes. I was just having a bit of a hard time following your
patch. I think this is clearer.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-13 12:24

Message:
Logged In: YES 
user_id=971153


>- The checkline() docstring needs to be updated.
>- Try not to use multi-line comments after a statement
>(e.g.: 'return False #it's not a func call, but rather', etc.).

Ok, I can resubmit a patch for these two


>- For consistency, Breakpoint.breakingline should probably
>be called func_firstlineno.

Well, I am not sure: func_firstlineno causes a wrong
association with
co_firstlineno (while these are almost never the same).
Furthermore,
the  name ".breakingline" reflects the purpose: "a line
number where to break", while, "func_firstlineno" is totatly
neutral..
 

>- Moving the 'bp.breakingline=frame.f_lineno' statement into
>an else: branch of the 'if bp.breakingline and
>(bp.breakingline != frame.f_lineno)' statement would
>probably make the logic clearer.

Are you suggesting to replace:

                if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
                bp.breakingline=frame.f_lineno

with:

               if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
               else: 
                    bp.breakingline=frame.f_lineno

Why do you think it's better? It's definitely more verbose, has
an extra indentation level and looking through the code I
see a lot of code which looks like:

if  (....):
    return
foo
bar
without the else: branch


Would the following be better?

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 

Thus making it explicit that there are really 2 decisions
being made:
1) do we need to set the breakingline
2) do we need to break here


I don't have any strong feelings regarding these 2 issues,
just want to make sure that I understand the problem





----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 08:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 08:39:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 08:40:01 2004
Subject: [Patches] [ python-Patches-1009444 ] bottom-to-top decorator
	application order
Message-ID: 

Patches item #1009444, was opened at 2004-08-14 23:39
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=1009444&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bottom-to-top decorator application order

Initial Comment:
If you read http://mail.python.org/pipermail/python-dev/2004-
August/047512.html you will find out that Guido meant for the 
application order to go bottom-to-top (or right-recursive if you 
think of it as being in a list).  That means that::

  @first
  @second
  def blah(): pass

will end up doing::

  blah = first(second(blah))

The attached patch fixes Python/compile.c to follow this order and 
changes Lib/test/test_decorators.py to test for this order.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009444&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 09:32:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 09:32:27 2004
Subject: [Patches] [ python-Patches-1009444 ] bottom-to-top decorator
	application order
Message-ID: 

Patches item #1009444, was opened at 2004-08-14 23:39
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009444&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Brett Cannon (bcannon)
>Assigned to: Brett Cannon (bcannon)
Summary: bottom-to-top decorator application order

Initial Comment:
If you read http://mail.python.org/pipermail/python-dev/2004-
August/047512.html you will find out that Guido meant for the 
application order to go bottom-to-top (or right-recursive if you 
think of it as being in a list).  That means that::

  @first
  @second
  def blah(): pass

will end up doing::

  blah = first(second(blah))

The attached patch fixes Python/compile.c to follow this order and 
changes Lib/test/test_decorators.py to test for this order.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-08-15 00:32

Message:
Logged In: YES 
user_id=357491

Well, I went ahead and applied the patch figuring it was just so simple 
and the tests passed it was silly to wait for people to check a two line 
change in Python/compile.c .

Applied as:
* Python/compile.c
      rev. 2.318
* Lib/test/test_decorators.py
      rev. 1.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009444&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 14:26:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 14:26:09 2004
Subject: [Patches] [ python-Patches-1009384 ] Docstring fix in Modules/_csv.c
Message-ID: 

Patches item #1009384, was opened at 2004-08-15 03:12
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009384&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docstring fix in Modules/_csv.c

Initial Comment:
The ``\r\n`` in a docstring weren't quoted, resulting
in a newline, which was not intended.

Used the occasion to also remove random indentation a
few lines below.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:26

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.15 of _csv.c. Thanks for the patch!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009384&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 14:41:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 14:41:26 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 14:56:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 14:57:01 2004
Subject: [Patches] [ python-Patches-1006219 ] make inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: make inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:56

Message:
Logged In: YES 
user_id=469548

Handling one-line functions fixes problem 1 reported in
http://python.org/sf/769569.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 14:57:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 14:57:43 2004
Subject: [Patches] [ python-Patches-1009384 ] Docstring fix in Modules/_csv.c
Message-ID: 

Patches item #1009384, was opened at 2004-08-15 03:12
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009384&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Cherniavsky Beni (cben)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Docstring fix in Modules/_csv.c

Initial Comment:
The ``\r\n`` in a docstring weren't quoted, resulting
in a newline, which was not intended.

Used the occasion to also remove random indentation a
few lines below.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:26

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.15 of _csv.c. Thanks for the patch!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009384&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 15:14:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 15:14:39 2004
Subject: [Patches] [ python-Patches-713428 ] Fixes for 'commands' module on
	win32
Message-ID: 

Patches item #713428, was opened at 2003-04-01 19:51
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Gregory Warnes (warnes)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Fixes for 'commands' module on win32

Initial Comment:
Currently the 'commands' module is provided with python
on Win32 systems, but does not function properly.  (The
library reference says it is only available on Unix).    

The commands module provides 3 functions:

       getoutput(cmd)              returns output
generated by executing 'cmd' in a shell
       getstatusoutput(cmd)     returns (status,output)
generated by executing 'cmd' in a shell
       getstatus(file)                returns output of
"ls -ld file"

Below is a simple patch which enables 'getoutput' and
'getstatusoutut' to work properly on Win32. Since
'getstatusfile' only makes sense on Unix, the patch
prevents it from being defined on Win32.  The current
behavior is maintained on all other platforms.





----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:14

Message:
Logged In: YES 
user_id=469548

The commands module is going to stay Unix-specific. There
are too many potential issues with trying to support the
various win32 command interpreters. See
http://mail.python.org/pipermail/python-dev/2004-August/047774.html
and its responses.

----------------------------------------------------------------------

Comment By: Gregory Warnes (warnes)
Date: 2003-04-24 18:07

Message:
Logged In: YES 
user_id=9316

2nd attempt to upload fixed patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-24 17:02

Message:
Logged In: YES 
user_id=21627

Apparently, you did not check the checkbox. Can you please 
retry?

----------------------------------------------------------------------

Comment By: Gregory Warnes (warnes)
Date: 2003-04-10 06:50

Message:
Logged In: YES 
user_id=9316

Uploaded a revised patch file, as requested.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-08 08:02

Message:
Logged In: YES 
user_id=21627

Can you please resubmit this as a unified diff? Also, please
make sure you don't incude white-space only changes: Your
patch says that it changes all lines, just because you add a
CR at the end of every line (so either convert the modified
file to Unix conventions, or the original file to Windows
conventions).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=713428&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 15:14:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 15:15:00 2004
Subject: [Patches] [ python-Patches-889949 ] Make `commands' module work on
	Windows
Message-ID: 

Patches item #889949, was opened at 2004-02-03 21:58
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889949&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make `commands' module work on Windows

Initial Comment:
Currently the `commands' module does not work on windows.
A small patch fix this.
`getstatus' is not created on windows.

Miki

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:14

Message:
Logged In: YES 
user_id=469548

The commands module is going to stay Unix-specific. There
are too many potential issues with trying to support the
various win32 command interpreters. See
http://mail.python.org/pipermail/python-dev/2004-August/047774.html
and its responses.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889949&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 15:15:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 15:15:16 2004
Subject: [Patches] [ python-Patches-889949 ] Make `commands' module work on
	Windows
Message-ID: 

Patches item #889949, was opened at 2004-02-03 21:58
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889949&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make `commands' module work on Windows

Initial Comment:
Currently the `commands' module does not work on windows.
A small patch fix this.
`getstatus' is not created on windows.

Miki

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:14

Message:
Logged In: YES 
user_id=469548

The commands module is going to stay Unix-specific. There
are too many potential issues with trying to support the
various win32 command interpreters. See
http://mail.python.org/pipermail/python-dev/2004-August/047774.html
and its responses.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889949&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 15:15:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 15:17:27 2004
Subject: [Patches] [ python-Patches-660505 ] make commands.getstatusoutput
	work on windows
Message-ID: 

Patches item #660505, was opened at 2002-12-31 21:24
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660505&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Aleksandar Totic (atotic)
Assigned to: Nobody/Anonymous (nobody)
Summary: make commands.getstatusoutput work on windows

Initial Comment:
The following patch makes commands.getstatusoutput 
work on windows NT. Original code:
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

did not work on window's cmd.exe. This is because 
cmd.exe does not support "{}" command blocks.

To my knowledge, cmd.exe does not support command 
blocks at all. So the patch simply executes the 
command on nt, without any wrapping beyond adding 
redirection.

old code: (r 1.15)
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

new code:
if (os.name == 'nt'):
    pipe = os.popen(cmd + ' 2>&1', 'r')
else:
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

this is CVS Python source on Dec 31st, 2002, running 
on Windows XP professional.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:15

Message:
Logged In: YES 
user_id=469548

The commands module is going to stay Unix-specific. There
are too many potential issues with trying to support the
various win32 command interpreters. See
http://mail.python.org/pipermail/python-dev/2004-August/047774.html
and its responses.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660505&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 15:23:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 15:24:25 2004
Subject: [Patches] [ python-Patches-772029 ] Make commands.getstatusoutput
	work on Windows
Message-ID: 

Patches item #772029, was opened at 2003-07-16 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=772029&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Emin Martinian (emin63)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make commands.getstatusoutput work on Windows

Initial Comment:
The commands.getstatusoutput function does not
currently work on Windows because windows doesn't like
curly braces in shell commands.  By checking the name
of the OS using os.name and not using curly braces when
os.name == 'dos' or os.name == 'nt', the
getstatusoutput can be made to work on Windows.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:23

Message:
Logged In: YES 
user_id=469548

The commands module is going to stay Unix-specific. There
are too many potential issues with trying to support the
various win32 command interpreters. See
http://mail.python.org/pipermail/python-dev/2004-August/047774.ht
ml and its responses.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=772029&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 15:54:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 15:54:25 2004
Subject: [Patches] [ python-Patches-726204 ] help() with readline support
Message-ID: 

Patches item #726204, was opened at 2003-04-23 14:03
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: help() with readline support

Initial Comment:
This is a small patch to the Lib/pydoc.py implementing
command line editing capabilities (and optional
readline support) for the help() builtin.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:54

Message:
Logged In: YES 
user_id=469548

The patch was small, but I've tried to make it even smaller.
Introducing a subclass seemed unnecessary to me, I just used:

if self.input is sys.stdin and self.output is self.stdout:

in getline(). I'll check this in if you don't have any
problems with my patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 16:09:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 16:09:11 2004
Subject: [Patches] [ python-Patches-1006629 ] Match Solaris def'n of
	_XOPEN_SOURCE
Message-ID: 

Patches item #1006629, was opened at 2004-08-10 10:00
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006629&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Match Solaris def'n of _XOPEN_SOURCE

Initial Comment:
Per discussion on python-dev attached is a patch that
causes the _XOPEN_SOURCE definition to match that
defined by G++ on Solaris.  This is the simplest
patch I could come up with.  Perhaps better would be 
to discover the value and use that instead of simply
setting it to 500.  My configure skills weren't up to the
task though.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-08-15 09:09

Message:
Logged In: YES 
user_id=44345

Checked in as configure.in 1.466, configure 1.453


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-12 08:09

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006629&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 16:43:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 16:43:33 2004
Subject: [Patches] [ python-Patches-1006219 ] inspect.getsource show
	@decorators and one-liners
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Settings changed) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
>Summary: inspect.getsource show @decorators and one-liners

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:56

Message:
Logged In: YES 
user_id=469548

Handling one-line functions fixes problem 1 reported in
http://python.org/sf/769569.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 17:07:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 17:07:44 2004
Subject: [Patches] [ python-Patches-1009560 ] Fix @decorator evaluation order
Message-ID: 

Patches item #1009560, was opened at 2004-08-15 15: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=1009560&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix @decorator evaluation order

Initial Comment:
This patch fixes decorator evaluation order
and makes newlines between decorators
mandatory.

Changes in this patch:

     - Change Grammar/Grammar to require
       newlines between adjacent decorators.
       
     - Fix order of evaluation of decorators
       in the C (compile.c) and python
       (Lib/compiler/pycodegen.py) compilers
     
     - Add better order of evaluation check
       to test_decorators.py (test_eval_order)

     - Update the decorator documentation in
       the reference manual (improve description
       of evaluation order and update syntax
       description)

The order of evaluation issue is slightly
more subtle than it first appears - there
are two orders involved:

    - evaluation of decorator expressions
    - evaluation of the returned decorators

This patch arranges for the evaluation order
to be exactly the same as you get with the
manual way of writing decorators, which I
think is the least surprising way of doing
things.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009560&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 17:34:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 17:34:36 2004
Subject: [Patches] [ python-Patches-1006219 ] inspect.getsource show
	@decorators and one-liners
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getsource show @decorators and one-liners

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-08-15 17:34

Message:
Logged In: YES 
user_id=329382

Added tests for the patch.

Note that the patch for showing one-liners breaks two-line
lambdas.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:56

Message:
Logged In: YES 
user_id=469548

Handling one-line functions fixes problem 1 reported in
http://python.org/sf/769569.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 17:36:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 17:36:52 2004
Subject: [Patches] [ python-Patches-1006219 ] inspect.getsource show
	@decorators and one-liners
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Settings changed) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: inspect.getsource show @decorators and one-liners

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-15 17:34

Message:
Logged In: YES 
user_id=329382

Added tests for the patch.

Note that the patch for showing one-liners breaks two-line
lambdas.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:56

Message:
Logged In: YES 
user_id=469548

Handling one-line functions fixes problem 1 reported in
http://python.org/sf/769569.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 17:44:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 17:44:28 2004
Subject: [Patches] [ python-Patches-1006219 ] inspect.getsource show
	@decorators and one-liners
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: inspect.getsource show @decorators and one-liners

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-08-15 17:44

Message:
Logged In: YES 
user_id=329382

Eh, that should be:

Note that the patch for showing one-liners breaks showing
the source of two-line lambdas. Only the first line shows.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-15 17:34

Message:
Logged In: YES 
user_id=329382

Added tests for the patch.

Note that the patch for showing one-liners breaks two-line
lambdas.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:56

Message:
Logged In: YES 
user_id=469548

Handling one-line functions fixes problem 1 reported in
http://python.org/sf/769569.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 19:01:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 19:01:07 2004
Subject: [Patches] [ python-Patches-675551 ] extending readline functionality
Message-ID: 

Patches item #675551, was opened at 2003-01-27 10:52
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Michal Vitecek (fufsource)
Assigned to: Skip Montanaro (montanaro)
Summary: extending readline functionality

Initial Comment:
this patch against vanilla 2.2.2 adds three new functions to module readline:

remove_history(pos) -- remove history entry specified by pos

replace_history_entry(pos, line) -- replace history entry specified by pos with the given line

get_history_buffer_size() -- get current number of history entries

the libreadline.tex is also modified.

thank you for your consideration.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-08-15 12:01

Message:
Logged In: YES 
user_id=44345

Sorry, I completely forgot about this.

I checked it in as readline.c 2.73 and libreadline.tex 1.16.  The
only change I made was to change the names to
remove_history_item and replace_history_item to match the
format of get_history_item.


----------------------------------------------------------------------

Comment By: Michal Vitecek (fufsource)
Date: 2003-07-01 06:51

Message:
Logged In: YES 
user_id=698198

hello,
attached is a new patch against today's (1.7.2003) cvs of
python.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-06-27 13:32

Message:
Logged In: YES 
user_id=44345

Michal,  Can you update this patch against the 2.3 (CVS) source?
I'll take a look at it for addition after the 2.3 release.


----------------------------------------------------------------------

Comment By: Michal Vitecek (fufsource)
Date: 2003-02-11 05:23

Message:
Logged In: YES 
user_id=698198

this patch is invalid as no functionality extensions are
allowed in a stable python version.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 19:17:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 19:17:40 2004
Subject: [Patches] [ python-Patches-1005466 ] fix inspect.getargs() crash on
	def foo((bar)) (bug #891637)
Message-ID: 

Patches item #1005466, was opened at 2004-08-08 13:29
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005466&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix inspect.getargs() crash on def foo((bar)) (bug #891637)

Initial Comment:
inspect.getargs() assumes that Python generates the
UNPACK_TUPLE or UNPACK_SEQUENCE bytecodes when a
sublist is used. However, when the sublist has length 1
Python just optimizes away those bytecodes. It only
generates a STORE_FAST, even though it does take the
path used for sublists. This patch fixes this case in
inspect.getargs().

This fixes http://python.org/sf/891637: pydoc crashes
on a class property.

----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2004-08-15 19:17

Message:
Logged In: YES 
user_id=60903

Fixed in
 - Lib/inspect.py 1.53 and 1.47.8.2
 - Lib/test/test_inspect.py 1.15 and 1.12.8.3


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1005466&group_id=5470
From noreply at sourceforge.net  Sun Aug 15 21:42:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 15 21:42:10 2004
Subject: [Patches] [ python-Patches-1009560 ] Fix @decorator evaluation order
Message-ID: 

Patches item #1009560, was opened at 2004-08-15 15:07
Message generated for change (Comment added) made by mark_t_russell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009560&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix @decorator evaluation order

Initial Comment:
This patch fixes decorator evaluation order
and makes newlines between decorators
mandatory.

Changes in this patch:

     - Change Grammar/Grammar to require
       newlines between adjacent decorators.
       
     - Fix order of evaluation of decorators
       in the C (compile.c) and python
       (Lib/compiler/pycodegen.py) compilers
     
     - Add better order of evaluation check
       to test_decorators.py (test_eval_order)

     - Update the decorator documentation in
       the reference manual (improve description
       of evaluation order and update syntax
       description)

The order of evaluation issue is slightly
more subtle than it first appears - there
are two orders involved:

    - evaluation of decorator expressions
    - evaluation of the returned decorators

This patch arranges for the evaluation order
to be exactly the same as you get with the
manual way of writing decorators, which I
think is the least surprising way of doing
things.


----------------------------------------------------------------------

>Comment By: Mark Russell (mark_t_russell)
Date: 2004-08-15 19:42

Message:
Logged In: YES 
user_id=1017234

Used Brett's evaluation order (see
http://mail.python.org/pipermail/python-dev/2004-August/047835.html)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009560&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 01:48:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 01:48:25 2004
Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS
	independent)
Message-ID: 

Patches item #681780, was opened at 2003-02-06 08:03
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Faster commonprefix (OS independent)

Initial Comment:
This routine is about 20% faster on a test set of 7 sets 
of strings run 100000 times each (I can provide the test 
if requested).  The longer the common prefix is, the 
faster the routine becomes relative to original 
commonprefix.

My only worry is that it might get rejected if it is 
considered too fancy; therefore I wasn't shy on 
commenting.

I think we should also write a commonpathprefix, that 
will do what commonprefix should do, being in the 
*path.py module.  I'll do that if none other does.

The provided patch is for posixpath.py and ntpath.py, 
but since it's OS neutral it should work as is.  It uses 
itertools for speed, though, so it is not backportable, but 
it can be if requested by substituting map for imap and a 
normal slice for islice.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2004-08-15 15:48

Message:
Logged In: YES 
user_id=86307

Sorry for commenting on a closed item, but it appears the
patched commonprefix has not made it beyond posixpath.py (at
any rate, it's  not in ntpath.py).  Perhaps the change can
be applied to the other path modules?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-31 13:47

Message:
Logged In: YES 
user_id=80475

Applied Terry Reedy's solution to Lib/posixpath.py 1.64.

His solution is at:

http://groups.google.com/groups?
th=fc7b54f11af6b24e&seekm=bss2so$om$5@news.t-
online.com

----------------------------------------------------------------------

Comment By: Sebastien Keim (s_keim)
Date: 2003-03-03 23:01

Message:
Logged In: YES 
user_id=498191

I would suggest another possibility. This one use a property
of strings 
ordering: if you have a<=b<=c and c.startswith(a) then
b.startswith(a).

I have tested two implementations :

# a 5 lines function with a really straightforward  code.
# It can degenerate rather badly in the worst case (large
strings 
# with a short common prefix) but is generally quite fast.
def commonprefix1(m):
    if not m: return ''
    prefix, greater = min(m), max(m)
    while not greater.startswith(prefix):
	prefix = prefix[:-1]
    return prefix

# The second use a bissection to avoid the worst case. This make
# the implementation a little more complex but seems to
provide the
# fastest result.
def commonprefix2(m):
    prefix = ''
    if m:
	low, high = min(m), max(m)
	while low:
	    n = len(low)//2 + 1
	    l, h = low[:n], high[:n]
	    if h==l:
		prefix += l
		low, high = low[n:], high[n:]
	    else:
		low, high = l[:-1], h
    return prefix
      
I personally prefer the commonprefix1 implementation: its
the simplest one and it is probably fast enough for the few
commonprefix use-cases (anyway, it is still faster than the
current implementation).      

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-02-07 02:11

Message:
Logged In: YES 
user_id=539787

I did my homework better, and found out that the buffer object 
quite probably will be deprecated.  So I rewrote the routine 
without the buffer object (using str.startswith), which by the 
way got another 10% speedup (relative to the latest version 
using buffer.)
The commonprefix_nobuf.diff patch applies directly to the 
original posixpath.py, ntpath.py.  I will try to delete the other 
patches, but I don't think I am allowed to do it.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-02-06 09:02

Message:
Logged In: YES 
user_id=539787

Best case: comparing this to the old version with a list: 
['/usr/local/lib/python2.3/posixpath.py']*120, 10000 iterations, 
the speed difference is:
old: 319.58 sec
new: 34.43 sec

Since prefix_len always grows in the "while next_bit:" loop, 
applying commonprefix2.diff to the *patched* version does a 
very minor speedup (comparing smaller buffers in every 
iteration); but it is only a matter of overoptimisation (ie it does 
not hurt, but it's a trivial one, just 0.1%).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-06 08:25

Message:
Logged In: YES 
user_id=33168

As much as I'd like to blame IE, it's a SF bug AFAIK.  
http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-02-06 08:04

Message:
Logged In: YES 
user_id=539787

For some reason, my IE never uploads the file on the first 
attempt.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470
From erica55 at bol.com.br  Mon Aug 16 06:20:33 2004
From: erica55 at bol.com.br (Erica Silveira)
Date: Mon Aug 16 06:20:17 2004
Subject: [Patches] listagem de e-mails
Message-ID: <20040816042015.B342A1E4005@bag.python.org>

Mais Emails, venda online de listas de email, fazemos mala direta e 
propaganda de sua empresa ou neg?cio para milh?es de emails. Temos listas 
de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, 
Mailing List, Milh?es de Emails, Programas de Envio de Email, Email 
Bombers, Extratores de Email, Listas Segmentadas de Email, Emails 
Segmentados, Emails em Massa, E-mails

http://www.promonet.mx.gs

Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista 
de Emails, Mailing List, Milh?es de Emails, Programas de Envio de Email, 
Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails 
Segmentados, Emails em Massa, E-mails

http://www.promonet.mx.gs
From noreply at sourceforge.net  Mon Aug 16 06:37:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 06:38:06 2004
Subject: [Patches] [ python-Patches-531629 ] Add multicall support to
	xmlrpclib
Message-ID: 

Patches item #531629, was opened at 2002-03-19 10:00
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531629&group_id=5470

Category: Library (Lib)
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Martin v. L?wis (loewis)
Summary: Add multicall support to xmlrpclib

Initial Comment:
Adds a new object to xmlrpclib that allows the user to 
boxcared XML-RPC requests e.g.

server_proxy = ServerProxy(...)
multicall = MultiCall(server_proxy)
multicall.add(2,3)
multicall.get_address("Guido")

add_result, address = multicall()

see http://www.xmlrpc.com/discuss/msgReader$1208



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-16 14:37

Message:
Logged In: YES 
user_id=29957

This patch broke Python 1.5.2 compatibility, as documented
in PEP 291, and at the top of the file :-/


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-01 00:50

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

libxmlrpclib.tex 1.15
xmlrpclib.py 1.31
NEWS 1.883


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531629&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 07:00:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 07:00:22 2004
Subject: [Patches] [ python-Patches-1009811 ] Add missing types to
	__builtin__
Message-ID: 

Patches item #1009811, was opened at 2004-08-16 01:00
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=1009811&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: James Y Knight (foom)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add missing types to __builtin__

Initial Comment:
Add most of the missing type objects to __builtin__.

Adds the following:
ellipsis (not to be confused with Ellipsis, which is the object of this 
type)
builtin_function_or_method
dictproxy
generator
PyCObject
classobj
instance
instancemethod
cell
NoneType
NotImplementedType
frame
function
module
traceback
code

Does not add the rest of the names mentioned in my email, as I'm 
unsure if they got an approval or were silently ignored. I'm not 
convinced that it's a good idea to put the rest in __builtin__, myself.

See also:

and


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 07:24:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 07:24:33 2004
Subject: [Patches] [ python-Patches-531629 ] Add multicall support to
	xmlrpclib
Message-ID: 

Patches item #531629, was opened at 2002-03-19 00:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531629&group_id=5470

Category: Library (Lib)
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Martin v. L?wis (loewis)
Summary: Add multicall support to xmlrpclib

Initial Comment:
Adds a new object to xmlrpclib that allows the user to 
boxcared XML-RPC requests e.g.

server_proxy = ServerProxy(...)
multicall = MultiCall(server_proxy)
multicall.add(2,3)
multicall.get_address("Guido")

add_result, address = multicall()

see http://www.xmlrpc.com/discuss/msgReader$1208



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-16 07:24

Message:
Logged In: YES 
user_id=21627

Do you think that 1.5.2 compatibility is still desirable? I
don't think so, and would prefer to change PEP 291 instead.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-16 06:37

Message:
Logged In: YES 
user_id=29957

This patch broke Python 1.5.2 compatibility, as documented
in PEP 291, and at the top of the file :-/


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-31 14:50

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

libxmlrpclib.tex 1.15
xmlrpclib.py 1.31
NEWS 1.883


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531629&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 09:02:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 09:02:53 2004
Subject: [Patches] [ python-Patches-1001864 ] Logger file objects
Message-ID: 

Patches item #1001864, was opened at 2004-08-02 11:35
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Vinay Sajip (vsajip)
Summary: Logger file objects

Initial Comment:
The logger can return a file like object for each error
level.
These file objects can be sent to any function
expecting a file object.

Example:
>> import logging
>> logging.basicConfig()
>> logger = logging.getLogger()
>> err = logger.getFileObject(logging.ERROR)
>> print >> err, "This is an error"
ERROR:root:This is an error
ERROR:root:

>> err.flush()
>> err.close()


----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2004-08-16 10:02

Message:
Logged In: YES 
user_id=358087

I guess "isatty" is not needed :-)

I wasn't sure about black lines, what if the user want to
add some black lines to make it easiter to read?

I just see log line as regula lines with a prefix so that
empty lines are only with a prefix.

Your call.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-08-10 19:12

Message:
Logged In: YES 
user_id=308438

It's also untidy that the blank line is printed. I can
change it so that if the message text is = "\n", it's not
printed.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-08-10 18:49

Message:
Logged In: YES 
user_id=308438

Nice, but I have a question about isatty. Is it needed?
According to the docs for file-like objects, it should not
be implemented unless associated with a real file or device.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-08-09 15:47

Message:
Logged In: YES 
user_id=358087

Hope it works now...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 13:03

Message:
Logged In: YES 
user_id=29957

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file. In addition, even if you
*did* check this checkbox, a bug in SourceForge
prevents attaching a file when *creating* an issue.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-09 13:03

Message:
Logged In: YES 
user_id=29957




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001864&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 09:25:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 09:25:24 2004
Subject: [Patches] [ python-Patches-726204 ] help() with readline support
Message-ID: 

Patches item #726204, was opened at 2003-04-23 16:03
Message generated for change (Comment added) made by hdima
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: help() with readline support

Initial Comment:
This is a small patch to the Lib/pydoc.py implementing
command line editing capabilities (and optional
readline support) for the help() builtin.

----------------------------------------------------------------------

>Comment By: Dmitry Vasiliev (hdima)
Date: 2004-08-16 11:25

Message:
Logged In: YES 
user_id=388573

Ok, I think it's reasonable compromise for now. :-)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 17:54

Message:
Logged In: YES 
user_id=469548

The patch was small, but I've tried to make it even smaller.
Introducing a subclass seemed unnecessary to me, I just used:

if self.input is sys.stdin and self.output is self.stdout:

in getline(). I'll check this in if you don't have any
problems with my patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 13:23:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 13:23:52 2004
Subject: [Patches] [ python-Patches-1009929 ] PyErr_Clear() vs.
	AsynchronousException
Message-ID: 

Patches item #1009929, was opened at 2004-08-16 11:23
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=1009929&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Michael Hudson (mwh)
Summary: PyErr_Clear() vs. AsynchronousException

Initial Comment:
The core uses PyErr_Clear() in quite a number of places, which is bad.  It can hide a genuine problem like a MemoryError or an infinite recursion.  Fixing all these places is very difficult: there are a lot of functions that pretend they can't fail.  Instead, the current patch extends the asynchronous thread exception mecanism recently introduced, and PyErr_Clear() sends such an asynchronous exception to the current thread if it detects an exception that should not be lost.

"Should not be lost" is defined as subclassing from the new AsyncronousException class.  The exception hierarchy now looks like:

Exception
|
+-- SystemExit
|
+-- StopIteration
|
+-- StandardError
|   +-- almost_all_the_XxxError
|
+-- AsynchronousException
|   +-- KeyboardInterrupt
|   +-- RuntimeError
|   +-- MemoryError
|
+-- Warning

Some more thinking about it would be welcome.  Maybe AsynchronousException and a few others should not subclass Exception at all, so that "except Exception" statements don't catch them.  Anyway, this patch alreaddy improves the situation, because you can catch and re-raise AsynchronousException (instead of, say, just KeyboardInterrupt).

Incompatibility note: in CVS, NotImplementedError is a subclass of RuntimeError.  With this patch it doesn't make sense any more, so NotImplementedError now inherits directly from StandardError.

Finally note that the patch is a first draft, not really tested and documented (though it's already nice to be able to Ctrl-C out of a long-running hasattr() call).  In particular I'm not entierely sure when the asynchronous exception will be re-raised (though it should always be shortly after the original faulty opcode).  I'm not sure the tracebacks coming from such exceptions will always be correct (e.g. they could point to a point after the one that triggered the exception, or even skip a few recursion levels entierely).

Assigning to mwh because he seems interested in the idea.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009929&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 17:01:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 17:02:17 2004
Subject: [Patches] [ python-Patches-873418 ] email/Message.py: del_param
	fails when specifying a header
Message-ID: 

Patches item #873418, was opened at 2004-01-08 19:08
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873418&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email/Message.py: del_param fails when specifying a header

Initial Comment:
[forwarded from http://bugs.debian.org/225421]

Consider the following code:

   import email.Message
   msg = email.Message.Message()
   msg.add_header('Content-Disposition', 'attachment',
filename='bud.gif')
   msg.del_param('filename', 'Content-Disposition')

According to the documentation, this should be the
correct syntax.
However, ValueError is raised in del_param.

   Traceback (most recent call last):
     File "pybug.py", line 4, in ?
       msg.del_param('filename', 'Content-Disposition')
     File "/usr/lib/python2.3/email/Message.py", line
675, in del_param
       for p, v in self.get_params(header,
unquote=requote):
   ValueError: need more than 1 value to unpack

It seems to me like a simple mistake of the argument
order in the get_params call. The included patch fixes
it, at least my program works again (maybe the same
mistake is made in more places).


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-08-16 11:01

Message:
Logged In: YES 
user_id=12800

Patch accepted.  Checked into Python 2.3 and 2.4 along with
test cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873418&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 18:53:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 18:53:47 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-16 11:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 10:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Mon Aug 16 19:04:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 16 19:08:56 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 12:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 11:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 10:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Aug 17 04:25:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 04:34:32 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 15:50
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 19:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 10:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 09:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 08:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 06:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-09 22:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 21:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 07:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 05:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-03 22:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 21:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 13:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 12:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 07:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 15:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 14:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 12:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 09:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 08:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 07:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 07:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 23:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many  attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 06:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-24 23:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 08:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 21:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 13:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 09:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 06:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 04:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 06:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 12:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 02:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 02:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-14 23:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 11:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 11:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-23 23:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 07:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 21:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 06:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Aug 17 14:08:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 14:09:02 2004
Subject: [Patches] [ python-Patches-1010677 ] thread Module Breaks
	PyGILState_Ensure()
Message-ID: 

Patches item #1010677, was opened at 2004-08-17 13: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=1010677&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Thompson (philthompson10)
Assigned to: Nobody/Anonymous (nobody)
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. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470
From noreply at sourceforge.net  Tue Aug 17 14:16:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 14:16:39 2004
Subject: [Patches] [ python-Patches-1010677 ] thread Module Breaks
	PyGILState_Ensure()
Message-ID: 

Patches item #1010677, was opened at 2004-08-17 13:08
Message generated for change (Settings changed) made by philthompson10
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: Open
Resolution: None
Priority: 5
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. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470
From noreply at sourceforge.net  Tue Aug 17 15:24:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 15:24:54 2004
Subject: [Patches] [ python-Patches-726204 ] help() with readline support
Message-ID: 

Patches item #726204, was opened at 2003-04-23 14:03
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470

Category: Library (Lib)
>Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: help() with readline support

Initial Comment:
This is a small patch to the Lib/pydoc.py implementing
command line editing capabilities (and optional
readline support) for the help() builtin.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-17 15:24

Message:
Logged In: YES 
user_id=469548

Ok, checked in as rev 1.95 of pydoc.py.

----------------------------------------------------------------------

Comment By: Dmitry Vasiliev (hdima)
Date: 2004-08-16 09:25

Message:
Logged In: YES 
user_id=388573

Ok, I think it's reasonable compromise for now. :-)

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 15:54

Message:
Logged In: YES 
user_id=469548

The patch was small, but I've tried to make it even smaller.
Introducing a subclass seemed unnecessary to me, I just used:

if self.input is sys.stdin and self.output is self.stdout:

in getline(). I'll check this in if you don't have any
problems with my patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=726204&group_id=5470
From noreply at sourceforge.net  Tue Aug 17 18:58:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 19:02:34 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-17 11:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 21:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 12:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 11:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 10:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Tue Aug 17 19:32:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 17 19:32:44 2004
Subject: [Patches] [ python-Patches-1009560 ] Fix @decorator evaluation order
Message-ID: 

Patches item #1009560, was opened at 2004-08-15 16:07
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009560&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mark Russell (mark_t_russell)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Fix @decorator evaluation order

Initial Comment:
This patch fixes decorator evaluation order
and makes newlines between decorators
mandatory.

Changes in this patch:

     - Change Grammar/Grammar to require
       newlines between adjacent decorators.
       
     - Fix order of evaluation of decorators
       in the C (compile.c) and python
       (Lib/compiler/pycodegen.py) compilers
     
     - Add better order of evaluation check
       to test_decorators.py (test_eval_order)

     - Update the decorator documentation in
       the reference manual (improve description
       of evaluation order and update syntax
       description)

The order of evaluation issue is slightly
more subtle than it first appears - there
are two orders involved:

    - evaluation of decorator expressions
    - evaluation of the returned decorators

This patch arranges for the evaluation order
to be exactly the same as you get with the
manual way of writing decorators, which I
think is the least surprising way of doing
things.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-17 18:32

Message:
Logged In: YES 
user_id=6656

Anthony couldn't get SF CVS to talk to him, so I've checked
this in as

Doc/ref/ref7.tex revision 1.40
Grammar/Grammar revision 1.51
Lib/compiler/pycodegen.py revision 1.72
Lib/compiler/transformer.py revision 1.43
Lib/test/test_decorators.py revision 1.5
Modules/parsermodule.c revision 2.84
Python/compile.c revision 2.319
Python/graminit.c revision 2.37


----------------------------------------------------------------------

Comment By: Mark Russell (mark_t_russell)
Date: 2004-08-15 20:42

Message:
Logged In: YES 
user_id=1017234

Used Brett's evaluation order (see
http://mail.python.org/pipermail/python-dev/2004-August/047835.html)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009560&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 03:12:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 03:12:32 2004
Subject: [Patches] [ python-Patches-1011123 ] Bad URL encoding in
	SimpleHTTPServer directory listing
Message-ID: 

Patches item #1011123, was opened at 2004-08-18 03: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=1011123&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Niels Diepeveen (nielsdi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad URL encoding in SimpleHTTPServer directory listing

Initial Comment:
The list_directory method of SimpleHTTPRequestHandler uses cgi.escape() to encode the filenames.
However, the HREF part should be encoded using urllib.quote(). This patch fixes that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011123&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 04:04:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 04:04:12 2004
Subject: [Patches] [ python-Patches-1011144 ] regex nit in encoding
	declarations
Message-ID: 

Patches item #1011144, was opened at 2004-08-18 11:04
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=1011144&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: regex nit in encoding declarations

Initial Comment:
This patch is related to bug #995522.

Reference Manual recommends that encoding 
declarations match the pattern
  "coding[=:]\s*([\w-_.]+)"
But this pattern has two problems.

1. - mark needs to be escaped or placed as the first 
character.
   (bug #995522)
2. \w is same as [a-zA-Z0-9_], so there's no need to 
include _ in [].

Then the pattern will become
  coding[=:]\s*([-\w.]+)

The patch is for PEP-0263 and Python Reference Manual.

Thanks.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011144&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 08:53:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 08:53:37 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 (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011240&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011240&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 13:07:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 13:07:56 2004
Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...)
Message-ID: 

Patches item #764217, was opened at 2003-07-01 23:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470

Category: Tkinter
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L?wis (loewis)
Summary: Fix for tkFont.Font(name=...)

Initial Comment:
tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font.

This simple fix handles the problem.

I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:07

Message:
Logged In: YES 
user_id=21627

I have committed this change as tkFont.py 1.6, NEWS 1.1099.
I have left __del__; the font is now deleted in __del__ if
it was created in __init__.


----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-06-01 19:28

Message:
Logged In: YES 
user_id=431773

Just a tickle, hoping this can get into Python 2.4

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-12-12 00:22

Message:
Logged In: YES 
user_id=431773

Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit".

There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming.

I see two solutions:
- Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue.
- Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 19:05

Message:
Logged In: YES 
user_id=431773

Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable).

The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step.

Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 18:43

Message:
Logged In: YES 
user_id=431773

I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used).

 I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress).

Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts.

Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 13:01

Message:
Logged In: YES 
user_id=21627

reowen, are you willing to revise the patch in this direction?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-13 17:57

Message:
Logged In: YES 
user_id=21627

While the bug might be worth fixing, I think the approach
taken is wrong. With the patch, it will invoke "font names"
for all new tkFont objects, which might be a significant
overhead.

To really preserve current behaviour, it should continue to
'font create', and fall back to 'font configure' in case of
an exception.

Actually, it is not clear what the right behaviour is in the
first place. 'font configure' would change the settings of
the existing font. If the name clash is by coincidence, it
would be better to raise an exception instead of silently
modifying the existing font.

In the face of ambiguity, refuse the temptation to guess.

So to really fix this, tkFont.forName (or tkFont.existing)
should be provided.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-13 17:32

Message:
Logged In: YES 
user_id=80475

The first part of the patch appears reasonable.  For the 
second part, it's a bit late for an API change.

Martin, is this bugfix okay for Py2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 13:14:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 13:14:58 2004
Subject: [Patches] [ python-Patches-517256 ] poor performance in xmlrpc
	response
Message-ID: 

Patches item #517256, was opened at 2002-02-14 00:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=517256&group_id=5470

Category: Library (Lib)
Group: Python 2.1.2
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: James Rucker (jamesrucker)
Assigned to: Fredrik Lundh (effbot)
Summary: poor performance in xmlrpc response

Initial Comment:
xmlrpclib.Transport.parse_response() (called from 
xmlrpclib.Transport.request()) is exhibiting poor 
performance - approx. 10x slower than expected.

I investigated based on using a simple app that sent a 
msg to a server, where all the server did was return 
the message back to the caller.  From profiling, it 
became clear that the return trip was taken 10x the 
time consumed by the client->server trip, and that the 
time was spent getting things across the wire.

parse_response() reads from a file object created via 
socket.makefile(), and as a result exhibits 
performance that is about an order of magnitude worse 
than what it would be if socket.recv() were used on 
the socket.  The patch provided uses socket.recv() 
when possible, to improve performance.

The patch provided is against revision 1.15.  Its use 
provides performance for the return trip that is more 
or less equivalent to that of the forward trip.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:14

Message:
Logged In: YES 
user_id=21627

This was integrated into xmlrpclib.py 1.19 long ago; closing
it as accepted.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-21 20:27

Message:
Logged In: YES 
user_id=31435

It's been 2 years since this report was updated.  Any chance 
of resolving it?  If not, please close it.

----------------------------------------------------------------------

Comment By: James Rucker (jamesrucker)
Date: 2002-03-19 20:47

Message:
Logged In: YES 
user_id=351540

HTTPConnection.getresponse() will close the socket and set
self.sock to null after instantiating response_class (by
default, this is HTTPResponse; note that HTTPResponse does a
makefile() and stores the result in self.fp) iff the newly
created response class instance's 'will_close' attribute is
true.   

My server is setting the Keep-alive header with a value of 1
(it is based on xmlrpcserver.py), which causes will_close to
evaluate to false.  In your case, I'm presuming that
will_close is being evaluated as false and thus the socket
(accessed via h._conn.sock) has been set to <None>.  Note
that when I removed the Keep-alive header, I witness the
behaviour you're seeing.

Thus, it seems that as it stands, the beneift of the change
will only be realized if Keep-alive is set or HTTP/1.1 is
used (and Keep-alive is either not specified or is set to
non-zero).

The following from httplib.py shows and explains how
'will_close' will be set (from httplib.py):

        conn = self.msg.getheader('connection')
        if conn:
            conn = conn.lower()
            # a "Connection: close" will always close the
connection. if we
            # don't see that and this is not HTTP/1.1, then
the connection will
            # close unless we see a Keep-Alive header.
            self.will_close = conn.find('close') != -1 or                               ( self.version != 11 and                                 not
self.msg.getheader('keep-alive') )
        else:
            # for HTTP/1.1, the connection will always
remain open
            # otherwise, it will remain open IFF we see a
Keep-Alive header
            self.will_close = self.version != 11 and                               not
self.msg.getheader('keep-alive')

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-19 10:24

Message:
Logged In: YES 
user_id=38376

What server did you use?  In all my test setups, 
h._conn.sock is None at the time parse_response
is called...

----------------------------------------------------------------------

Comment By: James Rucker (jamesrucker)
Date: 2002-03-17 17:13

Message:
Logged In: YES 
user_id=351540

The problem was discovered under FreeBSD 4.4.


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-17 14:30

Message:
Logged In: YES 
user_id=38376

James, what platform(s) did you use?

I'm not sure changing the parse_response() interface is
a good idea, but if this is a Windows-only problem, there
may be a slightly cleaner way to get the same end result.

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:14

Message:
Logged In: YES 
user_id=6380

My guess makefile() isn't buffering properly. This has been
a long-standing problem on Windows; I'm not sure if it's an
issue on Unix.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-01 15:34

Message:
Logged In: YES 
user_id=38376

looks fine to me.  I'll merge it with SLAB changes,
and will check it into the 2.3 codebase asap.

(we probably should try to figure out why makefile
causes a 10x slowdown too -- xmlrpclib isn't exactly
the only client library reading from a buffered
socket)

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 00:23

Message:
Logged In: YES 
user_id=6380

Fredrik, does this look OK to you?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=517256&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 13:36:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 13:36:37 2004
Subject: [Patches] [ python-Patches-521478 ] mailbox / fromline matching
Message-ID: 

Patches item #521478, was opened at 2002-02-22 15:54
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=521478&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Camiel Dobbelaar (camield)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: mailbox / fromline matching

Initial Comment:
mailbox.py does not parse this 'From' line correctly:
>From camield@sentia.nl Mon Apr 23 18:22:28 2001 +0200
                                                ^^^^^
This is because of the trailing timezone information, 
that the regex does not account for.

Also, 'From' should match at the beginning of the line.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:36

Message:
Logged In: YES 
user_id=21627

The patch, as it stands, appears to be incorrect. It is
looking for *two* empty lines between messages, whereas
folder conventionally contain only a single empty line; this
is also what Zawinski says.

If that was fixed, I think the patch would be acceptable -
mailbox.py currently does not implement the rule that the
From: line must be preceded with an empty line.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-21 20:31

Message:
Logged In: YES 
user_id=31435

Since the Monday in question happened over 2 years ago, the 
answer to Michael's question is apparently "no" .  
Barry, we're stretching the conventional meaning of "asap" 
here -- can you close this one way or t'other now?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:43

Message:
Logged In: YES 
user_id=6656

Anything going to happen here by Monday?

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-03-02 17:47

Message:
Logged In: YES 
user_id=12800

Re-opening and assigning to myself.  I'll take a look at
your patches asap.

----------------------------------------------------------------------

Comment By: Camiel Dobbelaar (camield)
Date: 2002-03-02 15:34

Message:
Logged In: YES 
user_id=466784

PortableUnixMailbox is not that useful, because it only
matches '^From '.  From-quoting is an even bigger mess then
From-headerlines, so that does not really help.

I submit a new diff that matches '\n\nFrom ' or
'<start-of-file>From ', which makes PortableUnixMailbox
useful for my purposes.  It is not that intrusive as the
comment in the mailbox.py suggests.







----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-03-01 22:42

Message:
Logged In: YES 
user_id=12800

IMO, Jamie Zawinski (author of the original mail/news reader
in Netscape among other accomplishments), wrote the
definitive answer on From_

http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html

As far as Python's support for this in the mailbox module,
for backwards compatibility, the UnixMailbox class has a
strict-ish interpretation of the From_ delimiter, which I
think should not change.  It also has a class called
PortableUnixMailbox which recognizes delimiters as specified
in JWZ's document.  Personally, if I was trolling over a
real world mbox file I'd only use PortableUnixMailbox (as
long as non-delimiter From_ lines were properly escaped -- I
have some code in Mailman which tries to intelligently "fix"
non-escaped mbox files).

I agree with the Rejected resolution.

----------------------------------------------------------------------

Comment By: Camiel Dobbelaar (camield)
Date: 2002-03-01 12:34

Message:
Logged In: YES 
user_id=466784

I have tracked this down to Pine, the mailreader. 

In imap/src/c-client/mail.c, it has this flag:
 static int notimezones = NIL;    /* write timezones in
"From " header */

(so timezones are written in the "From" lines by default)

I also found the following comment in imap/docs/FAQ in the
Pine distribution:

"""
So, good mail reading software only considers a line to be a
"From " line if it follows the actual specification for a
"From " line. This means, among other things, that the day
of week is fixed-format: "May 14", but "May  7" (note the
extra space) as opposed to "May 7".  ctime() format for the
date is the most common, although POSIX also allows a
numeric timezone after the year.
"""

While I don't consider Pine to be the ultimate mailreader,
its heritage may warrant that the 'From ' lines it creates
are considered 'standard'.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-28 23:37

Message:
Logged In: YES 
user_id=6380

That From line is simply illegal, or at least nonstandard.

If your system uses this nonstandard format, you can extend
the mailbox parser by overriding the ._isrealfromline
method.

The pattern doesn't need ^ because match() is used, which
only matches at the start of the line.

Rejected.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=521478&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 13:37:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 13:37:53 2004
Subject: [Patches] 
	[ python-Patches-549213 ] warn on assignment to None, True, False
Message-ID: 

Patches item #549213, was opened at 2002-04-26 21:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=549213&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: warn on assignment to None, True, False

Initial Comment:
This patch issues a warning when None, True, or False
is assigned to.  I don't know what the text of the
warning should say, but that's a minor matter.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:37

Message:
Logged In: YES 
user_id=21627

The patch is out of date: assignment to None is now an error.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-23 19:34

Message:
Logged In: YES 
user_id=6380

Alas, I spoke too soon. This patch broke some unit tests,
e.g. test_grammar.py; its seems it doesn't correctly
traverse into tuple-shaped arguments. It also causes some
warnings because there's code out there that assigns to True
and False in case it's being run under older Python versions.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-23 17:35

Message:
Logged In: YES 
user_id=6380

Checked in, compile.c 2.269.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-16 21:15

Message:
Logged In: YES 
user_id=6380

Yes, I'd like it to be. I think the nits (duplicate warnings
in some cases) can be banged out during alpha testing.
Jeremy, can you check this in? It needs a small note in
Misc/NEWS.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-12-14 15:17

Message:
Logged In: YES 
user_id=21627

Is this going to be part of Python 2.3?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 22:44

Message:
Logged In: YES 
user_id=6380

Better.  Some strange behavior remains:

from foo import None    # gives three warnings!
import None   # gives two warnings!

We need a test suite that systematically tests all cases.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-26 22:30

Message:
Logged In: YES 
user_id=31392

Here's an improved pass, although the calls are getting a
bit messy.  Not sure how worried I am, since I'd like to
replace this code anyway.  (The worry is that I don't get
around to replacing it before 2.3.)

Also, fix com_arglist() to do only the work that is necessary.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-26 21:34

Message:
Logged In: YES 
user_id=31392

Right.  I'll have to fiddle the patch to make the check into
a function and we can see where else it should be applied.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 21:28

Message:
Logged In: YES 
user_id=6380

Nice, but doesn't catch enough cases. E.g. using None as an
argument name, assigning to an attribute named None, "import
foo.None", "from foo.None import bar", "from None import
bar", "from None.foo import bar", using None as a keyword
argument in a call: "f(1, 2, None=3)".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=549213&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 13:40:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 13:40:05 2004
Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch
Message-ID: 

Patches item #597907, was opened at 2002-08-20 21:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Oren Tirosh's fastnames patch

Initial Comment:
Oren Tirosh had a nice patch to *really* speed up
global/builtin name lookup. I'm adding it here because
I don't want to lose this idea.

His code and some comments are here:

http://www.tothink.com/python/fastnames/

I'm uploading a new version of this patch relative to
current CVS.

I'm still considering whether to do this; I measure at
best a 1% speedup for pystone.

For a modified version of Oren's benchmark (modified to
use a function instead of a class for 'builtin' and
'global', so that these tests use LOAD_GLOBAL rather
than LOAD_NAME, I get these test results (best of 3):

   builtin 1.38
    global 1.54
     local 1.28
 fastlocal 0.90

Python 2.3 without his patch (but with my speedup hacks
in LOAD_GLOBAL):

   builtin 1.80
    global 1.52
     local 1.77
 fastlocal 0.91

Python 2.2 (from the 2.2 branch, which is newer than
the 2.2.1 release but doesn't have any speedups) did this:

   builtin 2.28
    global 1.86
     local 1.80
 fastlocal 1.10

I don't care about the speedup for the 'local' case,
since this uses the LOAD_NAME opcode which is only used
inside class definitions; the 'builtin' and 'global'
cases are interesting. It looks like Oren's patch gives
us a nice speedup for looking up a built-in name from a
function. I have to think about why looking up a global
from a function is slower though...

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:40

Message:
Logged In: YES 
user_id=21627

Closing the patch as withdrawn/won't fix.

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2003-07-06 22:55

Message:
Logged In: YES 
user_id=562624

I have announced a few month ago on the list that I am no longer 
working on it. If anyone wants to take over I'd be happy to explain the 
ideas I had for further development of this patch to usable state and 
better performance.  
 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-06 22:16

Message:
Logged In: YES 
user_id=357491

What is the status of the mysterious new patch, Oren?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-15 17:54

Message:
Logged In: YES 
user_id=6380

Hm, that patch doesn't have all the trickery here. Maybe
Oren can explain what his intentions were? I don't have time
to sort through all this -- if someone else wants to, that's
fine (I've got a feeling Oren has other priorities these days).

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-11-15 07:01

Message:
Logged In: YES 
user_id=250749

I notice Oren uploaded what appears to be an updated patch 
(fastnames5.patch) under patch #606098.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-11-15 06:57

Message:
Logged In: YES 
user_id=250749

I notice Oren uploaded what appears to be an updated patch 
(fastnames5.patch) under patch #606098.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 18:31

Message:
Logged In: YES 
user_id=6380

Lowered priority until Oren uploads his long-awaited new
version.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-23 18:35

Message:
Logged In: YES 
user_id=6380

Oren, any chance that you'll submit a new version of this?

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2002-09-03 22:22

Message:
Logged In: YES 
user_id=562624

> I'm still considering whether to do this; I measure at
> best a 1% speedup for pystone.

No surprising considering the fact that pystone is dominated
by fastlocals (IIRC it was something like 99.7% according to
my instrumented version).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-03 20:29

Message:
Logged In: YES 
user_id=6380

OK. I'm holding my breath! :-)

----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2002-09-02 21:59

Message:
Logged In: YES 
user_id=562624

I'm working on an improved version. Stay tuned!


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 21:31

Message:
Logged In: YES 
user_id=6380

Tim explained why the 'globals' case is faster than the
'builtins' case. I used 'x' as the global to look up rather
than 'hex', and it so happens that the last three bits of
hash('x') and hash('MANY') are the same -- MANY is an
identifier I insert in the globals.  I'll attach the test
suite I used (with 'hex' instead of 'x'). Now I get these times:

   builtin 1.39
    global 1.28
     local 1.29
 fastlocal 0.91


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 13:57:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 13:57:24 2004
Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation
Message-ID: 

Patches item #599331, was opened at 2002-08-23 19:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 1
Submitted By: Jon Riehl (jriehl)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 269 Implementation

Initial Comment:
The following are files for the implementation of PEP
269.  The primary changes to the core involve moving
required pgen modules from the pgen only module list to
the Python library module list in Makefile.pre.in. 
Some of the modules required better memory allocation
and management and the corresponding deallocators are
in the Python extension module (maybe these should be
moved into the pgen modules in Parser).

Initially included are two implementations.  The first
is a basic implementation that follows the PEP API more
or less.  The second (currently unfinished)
implementation provides a more object oriented
interface to the extension module.

Please note there are some commented out modifications
to setup.py as I was unable to build the extension
module(s) automagically.  For some reason the linker I
was using (on a BSD box) complained that it couldn't
find the _Py_pgen symbol, even though I verified its
existence in the new Python library.  Maybe it is
checking against an older Python library on the system?

Things to be done (as of initial submission) include
resolving on a single interface, documenting the one
true interface, and finishing any unimplemented
routines (such as are found in the OO implementation).

In the final integration, a pgenmodule.c file should be
added to the Modules directory in the main distribution.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:57

Message:
Logged In: YES 
user_id=21627

I have now marked the PEP as deferred, until some volunteer
picks it up again. I'm rejecting this patch (but left a
pointer in the PEP for reference).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-02 19:35

Message:
Logged In: YES 
user_id=21627

I was wondering what the possible next steps could be. With
your current analysis, it appears that
1. declare PEP 269 withdrawn
2. reject this patch
would be a possibility. I would want to keep this open only
if some volunteer would indicate interest in completing this
work.

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2003-11-02 00:20

Message:
Logged In: YES 
user_id=22448

I am to some extent.  I've done several wacky things, namely
putting the pgen extension module into my Basil project
(basically I think PEP 269 is dead), as well as re-written
pgen in "pure" Python (no C extension module calls)   The
pure Python pgen looks like it will be going into Pypy.  I
don't know if I am interested in the speed enough to warrant
serious analysis of the pgen C extension and the
segmentation fault Guido reported.  Let me know if you had
anything specific in mind.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-31 14:54

Message:
Logged In: YES 
user_id=21627

Jon, are you still interested in taking this further?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 17:12

Message:
Logged In: YES 
user_id=6380

I've checked in the changes to the parser and Makefile etc.
This means you should be able to distribute pgenmodule.c as
a clean extension to Python 2.3.

I've decided not to incorporate pgenmodule.c at this time.
There are three problems with it as I see it:

- The C coding style is really different, and makes it hard
to read: 2-space indents instead of tabs, spaces before left
parentheses in argument lists, space between * and name in
things like "PyObject * name", placement of curly braces,
reversal of arguments to comparisons (e.g. "NULL != x"), and
long strings of underscores in comments.

- The code isn't robust enough: I got a segfault (can't
remember after what sequence of events, sorry), and it
caused a SystemError (error return without exception set)
when the grammar file couldn't be read.

- The pgen API seems a bit strange -- some things that I
would expect to be methods of AST objects are functions in
the pgen module (even when a companion function *is* an AST
method).

- The unit test doesn't fit in the Python test framework.

- I cooked up a little expression grammar and tried to parse
a sample string, but all I got was exceptions. I guess I am
missing something, but there's no tutorial that explains me
how to do things (I was copying the code from test_pgen.py
which works :-( ).

Nevertheless, thanks for the work so far -- I'm sure at some
point pgen will be usable from Python!


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 22:44

Message:
Logged In: YES 
user_id=6380

OK, reading the README now...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-05 17:42

Message:
Logged In: YES 
user_id=6380

Closed. Jon, if you're still interested in this, upload
something new and reopen the patch (or I can do that).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 18:32

Message:
Logged In: YES 
user_id=6380

Lowering priority until Jon has his next version ready.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-13 06:35

Message:
Logged In: YES 
user_id=6380

Cool. Maybe I'll get to it, maybe not. :-(

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2002-09-12 20:04

Message:
Logged In: YES 
user_id=22448

Guido, as per my private message, I'll attempt to submit
another patch by the end of the month, pending resumption of
"work" on the 23rd.  Commitment of the memory allocation
patch is fine, and any future patches would be against the
updated pgen code (I don't have commit permissions, so
someone else will have to do this possibly.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-09 14:09

Message:
Logged In: YES 
user_id=6380

I looked a bit, and it's very raw - the author admits that.
Jon, are you still working on this? Do you have a more
polished version?

Maybe we can separate out the memory allocation patches and
commit these already? They don't break anything.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-03 21:44

Message:
Logged In: YES 
user_id=6380

I guess I'm going to hve to look at this to pronounce...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:19:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:19:27 2004
Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb
Message-ID: 

Patches item #790710, was opened at 2003-08-18 19:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gr?goire Dooms (dooms)
Assigned to: Guido van Rossum (gvanrossum)
Summary: breakpoint command lists in pdb

Initial Comment:
This patch enables the user to define a list of commands 
associated to a breakpoint. Those commands are executed 
whenever the given breakpoint makes the program stop 
execution. 
The "commands [bpnumber]" command works like in gdb. 
 
This patch is against the CVS HEAD, it has been tested with 
python 2.3. 
The documentation is updated too. 
 
 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:19

Message:
Logged In: YES 
user_id=21627

I like the feature, but the implementation is not acceptable
in its current form: it changes the prompt, and the rebinds
all existing commands so that they add to self.commands.

Instead of all this trickery, do_commands should invoke
cmdloop directly, and add precmd and do_end implementations;
overriding onecmd also might be an option.

In addition, the patch should avoid setting member variables
of pdb in cases where a local variable is sufficient (e.g.
lastcmd_back).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-21 00:02

Message:
Logged In: YES 
user_id=6380

I'm all for this, but don't have the bandwidth to review it.
Who does?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:28:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:28:16 2004
Subject: [Patches] [ python-Patches-791776 ] factor out SMTPHandler.emit
	date handling
Message-ID: 

Patches item #791776, was opened at 2003-08-20 10:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791776&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Andrew Gaul (gaul)
Assigned to: Nobody/Anonymous (nobody)
Summary: factor out SMTPHandler.emit date handling

Initial Comment:
Change SMTPHandler.emit to use email.Utils.formatdate
for date formatting.  This changes the format from

    Wdy, DD Mon YYYY HH:MM:SS GMT

to

    Wdy, DD Mon YYYY HH:MM:SS (+/-)DDDD

which is the preferred format for email messages
according to RFC 2822.  This format is also accepted by
the obsolete RFCs 822 and 1123, so there should be no
compatibility problems.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:28

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as handlers.py 1.17, NEWS
1.1100.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=791776&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:38:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:38:57 2004
Subject: [Patches] [ python-Patches-793070 ] Add --remove-source option to
	setup.py
Message-ID: 

Patches item #793070, was opened at 2003-08-22 12:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Fraser (davidfraser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add --remove-source option to setup.py

Initial Comment:
For distributing non-opensource software, it is helpful
to just distribute the .pyc/.pyo files and not the
original .py files.
The reverse (just distributing .py files) is possible
through the --no-target-compile and
--no-target-optimize switches to the distutils bdist
command.
We have added a --remove-source option which goes
through and deletes all the source files from the build
directory. This has been tested and works smoothly with
Python 2.2.3 and seems to apply cleanly to Python 2.3

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:38

Message:
Logged In: YES 
user_id=21627

The patch is still incorrect, though: it unconditionally
decides that bdist_wininst is now going to ship byte code.
This is incorrect, since the byte code can only belong to
the current Python version, which might be different from
the target Python version.

In addition, "removing all source" means to remove all .py
files. Instead, it should remove the files that are
byte-compiled, i.e. the files returned from
get_outputs(include_bytecode=0).

----------------------------------------------------------------------

Comment By: David Fraser (davidfraser)
Date: 2003-09-01 18:25

Message:
Logged In: YES 
user_id=221678

As far as I understand, the compiled files are generated in
the build dir from the source files which have been copied
there.
Simply removing the source files afterwards means we don't
have to make any changes to the whole way distutils operates. 
Also, we don't want to compile in-tree and then move the
files as that might create confusing results when compiling
for multiple versions of Python.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-31 18:18

Message:
Logged In: YES 
user_id=21627

Wouldn't it be better not to copy the files into the build
dir in the first place?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793070&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:46:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:47:01 2004
Subject: [Patches] [ python-Patches-800236 ] add HTTPResponse.getheaders()
Message-ID: 

Patches item #800236, was opened at 2003-09-04 07:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800236&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John Belmonte (jbelmonte)
Assigned to: Nobody/Anonymous (nobody)
Summary: add HTTPResponse.getheaders()

Initial Comment:
Here is a patch to Python 2.3b2+ to add a getheaders
method to class HTTPResponse in module httplib. 
Currently there is no way (using the public interface)
to discover response headers.  This is useful for
debugging, etc.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:46

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

libhttplib.tex 1.37
httplib.py 1.87
NEWS 1.1102


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=800236&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:48:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:48:26 2004
Subject: [Patches] [ python-Patches-802159 ] Suggested change in how
	ntpath.expanduser works
Message-ID: 

Patches item #802159, was opened at 2003-09-08 00:08
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802159&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jeffrey C. Jacobs (timehorse)
Assigned to: Nobody/Anonymous (nobody)
Summary: Suggested change in how ntpath.expanduser works

Initial Comment:
There exists a problem in the MS Knowledge base 
(http://support.microsoft.com/?kbid=236813) which 
documents some issues with using the %HOMEDRIVE% 
and %HOMEPATH% to generate a home directory.  
(Note, in XP systems these variables seeom to set 
correctly, though this problem exists in Win2k and likely 
WinNT.)  Given this and that in non-network situations 
these variables are not preferred I propose the changes 
explained in the following note:

Windows may be run over a network (Distributed File 
System or DFS) or as a stand-alone [multi-user] box.  In 
order to determine a tilde-expanded network path in a 
DFS environment, one must use the concatenation of %
HOMEDRIVE% and %HOMEPATH%.  In the stand-alone 
case, home directories are not part of a DFS path 
expansion.  On these machines, %HOMEDRIVE% and %
HOMEPATH% may default to "C:" [%SYSTEMDRIVE% ??] 
and "\", respectively.  While a %HOMEPATH% of "\" is 
quite common under DFS as well, if the "network" path 
is "C:" [or %SYSTEMDRIVE%], this is a stand-alone 
system and stand-alone rules should apply by default.  If 
however the %USERPROFILE% variable does not exist, 
the DFS interpretation will default and you still end up 
with "C:\" as your result.

The upshot of a stand-alone system is that other users 
can be tilde-expanded based on the variable %
ALLUSERSPROFILE%/../<name>, where name is the name 
given in the tilde.  However, since Windows allows 
whitespace names, the tilde must either be 8.3 
contracted or the fully-qualified user name.  This 
function will not verify if the name exits -- that is left to 
the caller's use of the result.  We require %
ALLUSERSPROFILE% rather than just manipulating %
USERPROFILE% to assure this is a multi-user system.

Finally, the local_path variable indicates whether 
the "My Documents" element should be appended.  On 
Win9x boxes which don't have a DFS path or %
USERPROFILE%, this translates typically to "C:\My 
Documents".  For NT, Win2k and XP, this typically 
means "%USERPROFILE%/My Documents".  This is 
because the profile is not a good directory to edit files 
in -- it is the equivalent to writing to a hidden system 
directory under UNIX.

Note however that we still prefer %HOME% because it 
was almost certainly manually set and this is not "My 
Documents" expanded.

A similar implementation can be provided in the 
dospath.expanduser method though here the "My 
Documents" expansion should only be used on Win9x 
machines, not true DOS systems.  Since the ntpath 
library SHOULD be imported on these Win9x systems 
(AFAICT from the Documentation) no change would 
therefore be necessary in dospath to support this.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:48

Message:
Logged In: YES 
user_id=21627

It appears that no update to this patch has been received -
considering it withdrawn.

----------------------------------------------------------------------

Comment By: Jeffrey C. Jacobs (timehorse)
Date: 2003-09-08 13:36

Message:
Logged In: YES 
user_id=836867

I forgot to mention this solution unfortunately would only 
work on English windows systems, as international Windows 
use the literal translation of "My Documents", e.g. "Mes 
Documents" for the official user folder.  I will look into how I 
might fix this problem in the generic case (perhaps by 
scanning the registry) but would also like to add perhaps 
given that Mac OS X has gone in this direction that there be 
a generic get_my_documents([user]), get_my_pictures
([user]) and get_my_desktop([user]) supported as stubs in 
those systems that don't support it and return the relavent 
directory for nt and OSX.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=802159&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:48:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:48:31 2004
Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb
Message-ID: 

Patches item #790710, was opened at 2003-08-18 17:52
Message generated for change (Comment added) made by dooms
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gr?goire Dooms (dooms)
Assigned to: Guido van Rossum (gvanrossum)
Summary: breakpoint command lists in pdb

Initial Comment:
This patch enables the user to define a list of commands 
associated to a breakpoint. Those commands are executed 
whenever the given breakpoint makes the program stop 
execution. 
The "commands [bpnumber]" command works like in gdb. 
 
This patch is against the CVS HEAD, it has been tested with 
python 2.3. 
The documentation is updated too. 
 
 

----------------------------------------------------------------------

>Comment By: Gr?goire Dooms (dooms)
Date: 2004-08-18 12:48

Message:
Logged In: YES 
user_id=846867

Ok, I see. 
This implementation is one year old. 
I'll recode this according to your comments. 
 
Why should'nt 'commands' change the prompt ? 
Should I assign to somebody else ? 
Are IDLE topics preferably discussed in idle-dev or 
python-dev mailing list ?   
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 12:19

Message:
Logged In: YES 
user_id=21627

I like the feature, but the implementation is not acceptable
in its current form: it changes the prompt, and the rebinds
all existing commands so that they add to self.commands.

Instead of all this trickery, do_commands should invoke
cmdloop directly, and add precmd and do_end implementations;
overriding onecmd also might be an option.

In addition, the patch should avoid setting member variables
of pdb in cases where a local variable is sufficient (e.g.
lastcmd_back).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 23:02

Message:
Logged In: YES 
user_id=6380

I'm all for this, but don't have the bandwidth to review it.
Who does?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:51:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:51:44 2004
Subject: [Patches] [ python-Patches-804885 ] Lib/email/Encoders.py iso-2022
	is 7bit
Message-ID: 

Patches item #804885, was opened at 2003-09-12 08:31
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804885&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lib/email/Encoders.py iso-2022 is 7bit

Initial Comment:
In email package, all the raw encoding is assumed 
8bit except us-ascii. This is not true for ISO-2022 
series of encodings eg. iso-2022-jp, which use escape 
sequence for charset transition and all the 
characters including multibyte are 8th bit 0. 
 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:51

Message:
Logged In: YES 
user_id=21627

This was committed as Encoders.py 1.8.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804885&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:54:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:54:46 2004
Subject: [Patches] [ python-Patches-845306 ] socketmodule.c: fix for
	platforms w/o IPV6 (i.e.Solaris 5.7)
Message-ID: 

Patches item #845306, was opened at 2003-11-19 19:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Matthew Bachmann (matt979)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7)

Initial Comment:

Fixes Bug #818490

socketmodule.c will not compile on platforms without 
IPV6 support such as Solaris 5.7 because the AF_INET6 
and INET_ADDRSTRLEN are used outside the 
ENABLE_IPV6 guarded sections. 

For example (lines 2971-2977):

#ifndef ENABLE_IPV6
    if(af == AF_INET6) {
        PyErr_SetString(socket_error,
                "can't use AF_INET6, IPv6 is disabled");
        return NULL;
    }
#endif

The code is putting error checking in when IPV6 is not 
supported, but it is using the AF_INET6 define which 
does not exist on platforms w/o IPV6.  

I simply removed the block and let the check fall to the 
inet_pton call.

I'm not so clear as what to do w/ INET_ADDRSTRLEN
define because I'm not knowledgable about its history.
At least under Solaris, INET_ADDRSTRLEN along with 
INET6_ADDRSTRLEN only appear w/ IPV6 support.

In the patch, I simply substituted it with 16 which is the 
value.  Since its just the number of characters in a 
dotted IP address, it seems like it would be pretty 
constant accross platforms.

The diff given is against the r232 cvs tag.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:54

Message:
Logged In: YES 
user_id=21627

Somethink like this has been committed as socketmodule.c 1.290.

----------------------------------------------------------------------

Comment By: Matthew Bachmann (matt979)
Date: 2003-12-05 20:40

Message:
Logged In: YES 
user_id=912994

Sounds good.  I guarded that code with:

#if ! defined(ENABLE_IPV6) && defined(AF_INET6)

Uploaded attached new patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-12-05 20:13

Message:
Logged In: YES 
user_id=21627

The patch is incorrect: The block checking for AF_INET6
should not be removed. On some systems, AF_INET6 might be
available, and using it with disabled IPv6 should cause an
exception.

Instead, you should check whether AF_INET6 is defined also.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:58:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:59:03 2004
Subject: [Patches] [ python-Patches-1006219 ] inspect.getsource show
	@decorators
Message-ID: 

Patches item #1006219, was opened at 2004-08-09 23:32
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Johannes Gijsbers (jlgijsbers)
>Summary: inspect.getsource show @decorators

Initial Comment:
The getsource function in inspect.py breaks badly with
the @decorators.

The inspect mechanism scans backwards from the topmost
decorator until it finds some acceptable statement (it
can be anything: another function, an import line, etc.).

The patch takes care of that. It'll print all
decorators for a function as well as the function itself.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-18 14:58

Message:
Logged In: YES 
user_id=469548

Okay, I've checked in the patch that handles decorators as
rev 1.54 of inspect.py and rev 1.16 of test_inspect.py (note
that I integrated your tests into this file).

The oneline and twoline cases in test_inspect_decorators.py
don't fail for me, even without the patch, so I'm not
applying a patch that breaks a previously working case . 

If you're still interested in fixing this, I suggest you
write down all the test cases that should work (including
http://python.org/sf/769569 and having a twoline lambda at
the end of a file), see whether they fail now and open a new
tracker item with a patch that fixes those that don't.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-15 17:44

Message:
Logged In: YES 
user_id=329382

Eh, that should be:

Note that the patch for showing one-liners breaks showing
the source of two-line lambdas. Only the first line shows.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-15 17:34

Message:
Logged In: YES 
user_id=329382

Added tests for the patch.

Note that the patch for showing one-liners breaks two-line
lambdas.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:56

Message:
Logged In: YES 
user_id=469548

Handling one-line functions fixes problem 1 reported in
http://python.org/sf/769569.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-15 14:41

Message:
Logged In: YES 
user_id=469548

The patch seems okay on casual inspection, but it still
needs to have tests. Feel free to assign it to me after
adding those.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-12 16:16

Message:
Logged In: YES 
user_id=329382

Also fix that getsource really doesn't handle one-line
functions, with new patch.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-11 20:22

Message:
Logged In: YES 
user_id=329382

Yes, it does.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-10 13:19

Message:
Logged In: YES 
user_id=329382

Yeah ... It doesn't really fix anything.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006219&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 14:59:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 14:59:41 2004
Subject: [Patches] [ python-Patches-823775 ] use just built python interp.
	to build the docs.
Message-ID: 

Patches item #823775, was opened at 2003-10-15 00:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823775&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Matthias Klose (doko)
Summary: use just built python interp. to build the docs.

Initial Comment:
this patch doesn't change the default behaviour, but
does allow passing a PYTHON interpreter for building
the docs. Of ycourse you could pass MKHOWTO as well,
but then you have to know the environmnet (TEXINPUTS)
as well. The "$(shell ...)" construct is already used,
so it does not introduce a new incompatibility.

[note: I think as the default the just built
interpreter should be used to build the docs]


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:59

Message:
Logged In: YES 
user_id=21627

As Makefile will always set PYTHON to python atleast, I
don't see the point of this patch anymore. I agree the
uncommented version could go - anybody who cannot set PYTHON
appropriately but still can edit the Makefile might just as
well remove $(PYTHON).

doko, please update the Makefile as you see fit, and close
this patch.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-11-16 11:23

Message:
Logged In: YES 
user_id=60903

attached is the patch for the trunk. I don't see much sense
in keeping the uncommented version, because the new
definition tries to cover both cases. Maybe Fred could
comment what he likes better.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-18 12:11

Message:
Logged In: YES 
user_id=21627

The patch does not apply to the CVS trunk. Please don't
remove the unused MKHOWTO line, and please provide separate
patches for 2.3 and the trunk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823775&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 15:13:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:13:32 2004
Subject: [Patches] [ python-Patches-992750 ] zipfile and big zipped file
Message-ID: 

Patches item #992750, was opened at 2004-07-17 09:45
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyphrene (keyphrene)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile and big zipped file

Initial Comment:
read method decompress the zipped files, but this
method returns bytes, more the file is big, more the
bytes array is big. readFile method allows to send the
bytes in a file.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 15:13

Message:
Logged In: YES 
user_id=21627

The patch is unacceptable in its current form. It duplicates
too much code; read and readfile should really share the
common code (e.g. by read falling back to readfile).

Also, as this really copies the data to fileobj, it probably
is better called copyfile, instead of readfile.

Finally, I would much prefer if zipfile would have an .open
method, returning a file-like object. Then you would have
such implementations

  def read(self, name):
      return self.open(name, "r").read()

  def readfile(self, name, dest):
      import shutil
      shutil.copyfileobj(self.open(name,"r"), dest)

I would then probably leave the last method out, and
encourage users to invoke shutil.copyfileobj directly if
desired.

Are you willing to make changes in this direction?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=992750&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 15:21:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:21:43 2004
Subject: [Patches] [ python-Patches-980082 ] Missing INCREF in PyType_Ready
Message-ID: 

Patches item #980082, was opened at 2004-06-26 02:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing INCREF in PyType_Ready

Initial Comment:
In PyType_Ready() if the type object you are readying 
does not explicitly define its tp_base value, it will 
default to use PyBaseObject_Type.

However, this assignment does not INCREF the 
PyBaseObject_Type pointer.  Thus, for heap allocated 
type objects, when the type_dealloc() function is 
called, a DECREF is called on tp_base which can 
eventually cause PyBaseObject_Type refcount go to 0, 
at which point bad things happen.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 15:21

Message:
Logged In: YES 
user_id=21627

I think the missing INCREF is a bug regardless of whether
the code is dead or not (if it is really dead, the bug is
that is hasn't been removed). I have committed the patch as
typeobject.c 2.263 and 2.241.6.12.

----------------------------------------------------------------------

Comment By: Eric Huss (ehuss)
Date: 2004-06-29 20:39

Message:
Logged In: YES 
user_id=393416

There are relatively few ways to make a heap allocated type 
object.  I have made a method to create structseq type 
objects on the heap (see sf patch 980098).  There doesn't 
appear to be a direct API to do it, so I did it manually.  Since 
the Type_Ready code has a check for NULL bases, one might 
as well take advantage of it.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-29 18:06

Message:
Logged In: YES 
user_id=6656

I'm not sure this is actually a real problem.  I don't think
you can get into the "base == NULL" case with a heap type...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980082&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 15:23:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:23:07 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: 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: 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 Aug 18 15:26:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:26:45 2004
Subject: [Patches] [ python-Patches-1011144 ] regex nit in encoding
	declarations
Message-ID: 

Patches item #1011144, was opened at 2004-08-18 04:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011144&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: regex nit in encoding declarations

Initial Comment:
This patch is related to bug #995522.

Reference Manual recommends that encoding 
declarations match the pattern
  "coding[=:]\s*([\w-_.]+)"
But this pattern has two problems.

1. - mark needs to be escaped or placed as the first 
character.
   (bug #995522)
2. \w is same as [a-zA-Z0-9_], so there's no need to 
include _ in [].

Then the pattern will become
  coding[=:]\s*([-\w.]+)

The patch is for PEP-0263 and Python Reference Manual.

Thanks.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 15:26

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as ref2.tex 1.54 and
pep-0263.txt 1.54.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011144&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 15:37:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:37:23 2004
Subject: [Patches] [ python-Patches-914291 ] Fix readline for utf-8 locales
Message-ID: 

Patches item #914291, was opened at 2004-03-11 18:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914291&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Michal Čihař (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix readline for utf-8 locales

Initial Comment:
When using utf-8 locales, readline doesn't work
correctly if not set LC_CTYPE to corresponding value.
This patch adds missing calls to setlocale (I'm not
sure whether it is really needed in setup_readline, but
it definitely is in call_readline.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 15:37

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. I have applied it as

NEWS 1.831.4.143
readline.c 2.75 2.64.6.2

Calling setlocale in setup_readline is unnecessary, as
setup_readline will call that itself, so I left that part
out of the patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914291&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 15:42:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:42:58 2004
Subject: [Patches] [ python-Patches-944928 ] Bugfix for dircheck() in
	Objects/fileobject.c
Message-ID: 

Patches item #944928, was opened at 2004-04-30 00:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=944928&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ulrich Berning (uberning)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugfix for dircheck() in Objects/fileobject.c

Initial Comment:
When the sys module is initialized in _PySys_Init(), it
creates file objects for stdin, stdout and stderr with
PyFile_FromFile() which calls fill_file_fields() to
initialize the file object. At the end of
initialization dircheck() is called, to ensure that the
file is not a directory. If the underlaying file
descriptors for stdin, stdout, stderr (0, 1, 2) are
closed by the parent process, dircheck() fails at least
on AIX. I don't know exactly why this fails but the
following expression in dircheck() 

if (fstat(fileno(f->f_fp), &buf) == 0 &&
S_ISDIR(buf.st_mode))

evaluates to True for stdin which results in setting an
exception and returning NULL to _PySys_Init().

The applied patch changes dircheck() to return without
further checks if the file object is for stdin, stdout
or stderr.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 15:42

Message:
Logged In: YES 
user_id=21627

This patch is not acceptable in this form. What you describe
seems to point to a clear bug in AIX, and, as other AIX
users have not reported that as a problem, appears to be
specific to your installation. Maybe there is a problem with
the compiler installation somehow?

If you want to investigate this further, please try to
reproduce the stat/ISDIR problem in a small stand-alone C
program. If that succeeds, please generate an
strace/ktrace/truss output for that binary.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=944928&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 15:58:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 15:58:41 2004
Subject: [Patches] [ python-Patches-995126 ] tarfile.py fix for bug #949052
Message-ID: 

Patches item #995126, was opened at 2004-07-21 12:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995126&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Lars Gust?bel (gustaebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py fix for bug #949052

Initial Comment:
Contained are two patches:

eisenmann.patch - a modified version of OP Simon
Eisenmann's patch that prevents tarfile.py from setting
the size attribute for directory members.

posix.patch - Simon brought up another issue:

tarfile.py operates in posix mode by default. My
original idea behind this was that it provides a higher
portability to other archiver programs (if they adhere
to the posix standard). Simon states that e.g. WinZip
is not able to read posix-compliant tar archives but
those with GNU extensions. So I think the idea of being
as portable as possible has proven false. GNU tar
format is a quasi-standard.

The second issue is that posix mode imposes several
limits - on pathname lengths in particular - since GNU
extensions are not allowed. For the average user, this
must be annoying, he does not care about posix and all
this portability stuff, he simply wants to add files
regardless of the length of their pathnames. But he
first has to search the docs and set TarFile's posix
attribute to False to enable GNU extensions. Even worse
is that e.g. backup scripts that run flawlessly for
months can suddenly fail just because there's a new
file with a long pathname that posix mode cannot handle.

To cut a long story short, I second Simon's proposal.
Since I contributed tarfile.py to Python's stdlib I had
the feeling I had made the wrong decision.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 15:58

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as

libtarfile.tex 1.5
tarfile.py 1.16
NEWS 1.1103

Because of the behaviour change, a backport to 2.3 is not
possible.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995126&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 16:00:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 16:00:53 2004
Subject: [Patches] [ python-Patches-995740 ] fix for title case bug: #995422
Message-ID: 

Patches item #995740, was opened at 2004-07-22 09:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995740&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Baris Metin (tbmetin)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for title case bug: #995422

Initial Comment:
Patch offers a solution for bug #995422.  
 
The basic idea in modification is changing the case in 
specified situations  We must  define the situations which 
changes the case.  
 
A simple aproach can be considering a case change if we 
are dealing with the first character of the string or the 
previous characters is a whitespace/punctuation. 
 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 16:00

Message:
Logged In: YES 
user_id=21627

I agree with Raymond; rejecting the patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 06:33

Message:
Logged In: YES 
user_id=80475

This patch should probably not be accepted.
See the discussion on the original bug report.
There are issues of international language conventions and
backwards compatability.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=995740&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 17:58:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 17:59:47 2004
Subject: [Patches] [ python-Patches-870286 ] make Demo/scripts/primes.py
	usable as a module
Message-ID: 

Patches item #870286, was opened at 2004-01-04 10:18
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470

Category: Demos and tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make Demo/scripts/primes.py usable as a module

Initial Comment:
I wanted to find all primes between 1985 and 2005, and
found out that Demo/scripts/primes.py is not usable as
a module, because it unconditionally executes main().
This patch adds a 'if __name__ == "__main__"' block
around the execution of the main() function, so that
one can simply import primes and use
primes.primes(1985, 2005) in order to achieve what I
wanted to achieve.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-18 17:58

Message:
Logged In: YES 
user_id=469548

Gerrit, are you still interested in doing this? I'll just
check in this patch if not.

----------------------------------------------------------------------

Comment By: Gerrit Holl (gerrit)
Date: 2004-01-17 15:58

Message:
Logged In: YES 
user_id=13298

Hm, I don't think I have enough mathematical knowledge to go
'all the way', although some of the suggestions are doable.
I'll have a look at it next week (week of Jan-26). 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-12 00:44

Message:
Logged In: YES 
user_id=80475

If you're going to improve this one, consider going all the way.

* Modernize the code -- the current version reads like Cobol
* Stop building the sieve after sqrt(MAX) entries have been
found.  Possibly use islice() to check only the relevant
entries in the primes table.
* Change the API to:  prime x [n]  which finds the first n
(default 1) primes larger than x.  prime(10,3) --> [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  Wed Aug 18 19:40:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 19:40:47 2004
Subject: [Patches] [ python-Patches-790710 ] breakpoint command lists in pdb
Message-ID: 

Patches item #790710, was opened at 2003-08-18 19:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gr?goire Dooms (dooms)
Assigned to: Guido van Rossum (gvanrossum)
Summary: breakpoint command lists in pdb

Initial Comment:
This patch enables the user to define a list of commands 
associated to a breakpoint. Those commands are executed 
whenever the given breakpoint makes the program stop 
execution. 
The "commands [bpnumber]" command works like in gdb. 
 
This patch is against the CVS HEAD, it has been tested with 
python 2.3. 
The documentation is updated too. 
 
 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 19:40

Message:
Logged In: YES 
user_id=21627

Oops. Changing the prompt itself is fine - I just disliked
the control flow that follows.

IDLE things can be discussed on either list, I guess, or
directly sent to kbk. If you mean changes, you best submit
them as a patch here to SF.

----------------------------------------------------------------------

Comment By: Gr?goire Dooms (dooms)
Date: 2004-08-18 14:48

Message:
Logged In: YES 
user_id=846867

Ok, I see. 
This implementation is one year old. 
I'll recode this according to your comments. 
 
Why should'nt 'commands' change the prompt ? 
Should I assign to somebody else ? 
Are IDLE topics preferably discussed in idle-dev or 
python-dev mailing list ?   
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:19

Message:
Logged In: YES 
user_id=21627

I like the feature, but the implementation is not acceptable
in its current form: it changes the prompt, and the rebinds
all existing commands so that they add to self.commands.

Instead of all this trickery, do_commands should invoke
cmdloop directly, and add precmd and do_end implementations;
overriding onecmd also might be an option.

In addition, the patch should avoid setting member variables
of pdb in cases where a local variable is sufficient (e.g.
lastcmd_back).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-21 00:02

Message:
Logged In: YES 
user_id=6380

I'm all for this, but don't have the bandwidth to review it.
Who does?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=790710&group_id=5470
From noreply at sourceforge.net  Wed Aug 18 21:29:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 18 21:29:41 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-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 Aug 19 00:04:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 00:04:59 2004
Subject: [Patches] [ python-Patches-1011822 ] Improve error reporting when
	Python opens source code
Message-ID: 

Patches item #1011822, was opened at 2004-08-18 22:04
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=1011822&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve error reporting when Python opens source code

Initial Comment:
Python gives the slightly unhelpful error message:
"can't open file %s" when given a bad file name.

Here's a patch to make Python's error reporting a
little more explicit when a user accidently mistypes
the name of a source file.  It's just a simple call to
strerror().  The patch is made against the Python-2.3.3
release.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011822&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 00:24:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 00:24:48 2004
Subject: [Patches] [ python-Patches-1011822 ] Improve error reporting when
	Python opens source code
Message-ID: 

Patches item #1011822, was opened at 2004-08-18 22:04
Message generated for change (Comment added) made by dyoo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011822&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve error reporting when Python opens source code

Initial Comment:
Python gives the slightly unhelpful error message:
"can't open file %s" when given a bad file name.

Here's a patch to make Python's error reporting a
little more explicit when a user accidently mistypes
the name of a source file.  It's just a simple call to
strerror().  The patch is made against the Python-2.3.3
release.



----------------------------------------------------------------------

>Comment By: Danny Yoo (dyoo)
Date: 2004-08-18 22:24

Message:
Logged In: YES 
user_id=49843

Modified the patch to more closely match error output from
Python.  Now prints "[Errno %d]" as well as the strerror().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011822&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 00:28:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 00:28:50 2004
Subject: [Patches] [ python-Patches-823775 ] use just built python interp.
	to build the docs.
Message-ID: 

Patches item #823775, was opened at 2003-10-15 00:58
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823775&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Matthias Klose (doko)
Summary: use just built python interp. to build the docs.

Initial Comment:
this patch doesn't change the default behaviour, but
does allow passing a PYTHON interpreter for building
the docs. Of ycourse you could pass MKHOWTO as well,
but then you have to know the environmnet (TEXINPUTS)
as well. The "$(shell ...)" construct is already used,
so it does not introduce a new incompatibility.

[note: I think as the default the just built
interpreter should be used to build the docs]


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2004-08-19 00:28

Message:
Logged In: YES 
user_id=60903

removed the commented definition of MKHOWTO macro
fixed in 1.277 of Doc/Makefile

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 14:59

Message:
Logged In: YES 
user_id=21627

As Makefile will always set PYTHON to python atleast, I
don't see the point of this patch anymore. I agree the
uncommented version could go - anybody who cannot set PYTHON
appropriately but still can edit the Makefile might just as
well remove $(PYTHON).

doko, please update the Makefile as you see fit, and close
this patch.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-11-16 11:23

Message:
Logged In: YES 
user_id=60903

attached is the patch for the trunk. I don't see much sense
in keeping the uncommented version, because the new
definition tries to cover both cases. Maybe Fred could
comment what he likes better.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-18 12:11

Message:
Logged In: YES 
user_id=21627

The patch does not apply to the CVS trunk. Please don't
remove the unused MKHOWTO line, and please provide separate
patches for 2.3 and the trunk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=823775&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 03:11:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 03:11:13 2004
Subject: [Patches] [ python-Patches-1011890 ] fix inspect.getsource breaking
	with line-continuation & more
Message-ID: 

Patches item #1011890, was opened at 2004-08-19 03:11
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=1011890&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix inspect.getsource breaking with line-continuation & more

Initial Comment:
The patch makes changes to inspect.py in two places:

* the pattern to match against functions at line 436 is
modified: lambdas should be matched even if not
preceded by whitespace, as long as "lambda" isn't part
of another word.

* the BlockFinder class is heavily modified. Changes are: 
  - checking for "def", "class" or "lambda" names
before setting self.started to True. Then checking the
same line for word characters after the colon (if the
colon is on that line). If so, and the line does not
end with a line continuation marker, raise EndOfBlock
immediately.
  - adding self.passline to show that the line is to be
included and no more checking is necessary on that
line. Since a NEWLINE token is not generated when a
line continuation marker exists, this allows getsource
to continue with these functions even if the following
line would not be indented.

The patch might be making a mess of the simple code,
and code such as code it now handles will probably not
be seen often. Still, it fixes the first bug shown in
"www.python.org/sf/769569".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 03:25:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 03:26:02 2004
Subject: [Patches] [ python-Patches-1011890 ] fix inspect.getsource breaking
	with line-continuation & more
Message-ID: 

Patches item #1011890, was opened at 2004-08-19 03:11
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix inspect.getsource breaking with line-continuation & more

Initial Comment:
The patch makes changes to inspect.py in two places:

* the pattern to match against functions at line 436 is
modified: lambdas should be matched even if not
preceded by whitespace, as long as "lambda" isn't part
of another word.

* the BlockFinder class is heavily modified. Changes are: 
  - checking for "def", "class" or "lambda" names
before setting self.started to True. Then checking the
same line for word characters after the colon (if the
colon is on that line). If so, and the line does not
end with a line continuation marker, raise EndOfBlock
immediately.
  - adding self.passline to show that the line is to be
included and no more checking is necessary on that
line. Since a NEWLINE token is not generated when a
line continuation marker exists, this allows getsource
to continue with these functions even if the following
line would not be indented.

The patch might be making a mess of the simple code,
and code such as code it now handles will probably not
be seen often. Still, it fixes the first bug shown in
"www.python.org/sf/769569".

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:25

Message:
Logged In: YES 
user_id=329382

BTW: inspect.py CVS HEAD passes three of the tests:
test_oll, test_tlli and test_onelinefunc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 05:30:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 05:30:28 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 15:50
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-08-18 20:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 09:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 19:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 10:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 09:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 08:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 06:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-09 22:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 21:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 07:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 05:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-03 22:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 21:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 13:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 12:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 07:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 15:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 14:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 12:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 09:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 08:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 07:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 07:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 23:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 06:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-24 23:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 08:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 21:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 13:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 09:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 06:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 04:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 06:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 12:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 02:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 02:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-14 23:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 11:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 11:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-23 23:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 07:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 21:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 06:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 05:57:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 05:57:06 2004
Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation
Message-ID: 

Patches item #599331, was opened at 2002-08-23 13:03
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 1
Submitted By: Jon Riehl (jriehl)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 269 Implementation

Initial Comment:
The following are files for the implementation of PEP
269.  The primary changes to the core involve moving
required pgen modules from the pgen only module list to
the Python library module list in Makefile.pre.in. 
Some of the modules required better memory allocation
and management and the corresponding deallocators are
in the Python extension module (maybe these should be
moved into the pgen modules in Parser).

Initially included are two implementations.  The first
is a basic implementation that follows the PEP API more
or less.  The second (currently unfinished)
implementation provides a more object oriented
interface to the extension module.

Please note there are some commented out modifications
to setup.py as I was unable to build the extension
module(s) automagically.  For some reason the linker I
was using (on a BSD box) complained that it couldn't
find the _Py_pgen symbol, even though I verified its
existence in the new Python library.  Maybe it is
checking against an older Python library on the system?

Things to be done (as of initial submission) include
resolving on a single interface, documenting the one
true interface, and finishing any unimplemented
routines (such as are found in the OO implementation).

In the final integration, a pgenmodule.c file should be
added to the Modules directory in the main distribution.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-18 23:57

Message:
Logged In: YES 
user_id=6380

FWIW, I *also* rewrote pgen in Python. Is the Pypy version
real? If so, I ma not have to publish my code (which is
owned by Elemental Security but if there's demand I can
attempt to open-source it).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 07:57

Message:
Logged In: YES 
user_id=21627

I have now marked the PEP as deferred, until some volunteer
picks it up again. I'm rejecting this patch (but left a
pointer in the PEP for reference).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-02 13:35

Message:
Logged In: YES 
user_id=21627

I was wondering what the possible next steps could be. With
your current analysis, it appears that
1. declare PEP 269 withdrawn
2. reject this patch
would be a possibility. I would want to keep this open only
if some volunteer would indicate interest in completing this
work.

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2003-11-01 18:20

Message:
Logged In: YES 
user_id=22448

I am to some extent.  I've done several wacky things, namely
putting the pgen extension module into my Basil project
(basically I think PEP 269 is dead), as well as re-written
pgen in "pure" Python (no C extension module calls)   The
pure Python pgen looks like it will be going into Pypy.  I
don't know if I am interested in the speed enough to warrant
serious analysis of the pgen C extension and the
segmentation fault Guido reported.  Let me know if you had
anything specific in mind.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-31 08:54

Message:
Logged In: YES 
user_id=21627

Jon, are you still interested in taking this further?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 11:12

Message:
Logged In: YES 
user_id=6380

I've checked in the changes to the parser and Makefile etc.
This means you should be able to distribute pgenmodule.c as
a clean extension to Python 2.3.

I've decided not to incorporate pgenmodule.c at this time.
There are three problems with it as I see it:

- The C coding style is really different, and makes it hard
to read: 2-space indents instead of tabs, spaces before left
parentheses in argument lists, space between * and name in
things like "PyObject * name", placement of curly braces,
reversal of arguments to comparisons (e.g. "NULL != x"), and
long strings of underscores in comments.

- The code isn't robust enough: I got a segfault (can't
remember after what sequence of events, sorry), and it
caused a SystemError (error return without exception set)
when the grammar file couldn't be read.

- The pgen API seems a bit strange -- some things that I
would expect to be methods of AST objects are functions in
the pgen module (even when a companion function *is* an AST
method).

- The unit test doesn't fit in the Python test framework.

- I cooked up a little expression grammar and tried to parse
a sample string, but all I got was exceptions. I guess I am
missing something, but there's no tutorial that explains me
how to do things (I was copying the code from test_pgen.py
which works :-( ).

Nevertheless, thanks for the work so far -- I'm sure at some
point pgen will be usable from Python!


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 16:44

Message:
Logged In: YES 
user_id=6380

OK, reading the README now...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-05 11:42

Message:
Logged In: YES 
user_id=6380

Closed. Jon, if you're still interested in this, upload
something new and reopen the patch (or I can do that).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 12:32

Message:
Logged In: YES 
user_id=6380

Lowering priority until Jon has his next version ready.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-13 00:35

Message:
Logged In: YES 
user_id=6380

Cool. Maybe I'll get to it, maybe not. :-(

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2002-09-12 14:04

Message:
Logged In: YES 
user_id=22448

Guido, as per my private message, I'll attempt to submit
another patch by the end of the month, pending resumption of
"work" on the 23rd.  Commitment of the memory allocation
patch is fine, and any future patches would be against the
updated pgen code (I don't have commit permissions, so
someone else will have to do this possibly.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-09 08:09

Message:
Logged In: YES 
user_id=6380

I looked a bit, and it's very raw - the author admits that.
Jon, are you still working on this? Do you have a more
polished version?

Maybe we can separate out the memory allocation patches and
commit these already? They don't break anything.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-03 15:44

Message:
Logged In: YES 
user_id=6380

I guess I'm going to hve to look at this to pronounce...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 08:08:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 08:08:53 2004
Subject: [Patches] [ python-Patches-1007068 ] baseinteger: abstract
	superclass for int and long
Message-ID: 

Patches item #1007068, was opened at 2004-08-11 03:20
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: baseinteger: abstract superclass for int and long

Initial Comment:
Quote from PEP-237
(http://www.python.org/peps/pep-0237.html):

"""
A new type, integer, may be introduced that is an
abstract base type of which both the int and long
implementation types are subclassed.  This is useful so
that programs can check integer-ness with a single test:

    if isinstance(i, integer): ...
"""

The patch implement the superclass for int and long
with name 'baseinteger'.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-19 02:08

Message:
Logged In: YES 
user_id=6380

I take it back. Few people on python-dev cared about this,
and there's at least one potential abuse (subclassing from
it won't do the right thing). It's also something that will
go away again in 3.0 (where there will be only one integral
type). Let's just by convention write isinstance(x,
(int,long)) when we really need it.

You may ask what about basestring? Its use case is similarly
weak, and I expect it to disappear in 3.0. Let's not repeat
the mistake.

So I'm rejecting this now. Sorry!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-13 10:43

Message:
Logged In: YES 
user_id=6380

+1

One suggestion: I'd add some words to the docs to recommend
*not* to use this for one's own integer-ish class. Instead,
subclassing from int or long is recommended, to avoid
confusion (since many built-in operations and extensions
accept only "genuine" integers, i.e. int or long or
subclasses thereof).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 13:08:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 13:08:34 2004
Subject: [Patches] [ python-Patches-1011822 ] Improve error reporting when
	Python opens source code
Message-ID: 

Patches item #1011822, was opened at 2004-08-19 00:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011822&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve error reporting when Python opens source code

Initial Comment:
Python gives the slightly unhelpful error message:
"can't open file %s" when given a bad file name.

Here's a patch to make Python's error reporting a
little more explicit when a user accidently mistypes
the name of a source file.  It's just a simple call to
strerror().  The patch is made against the Python-2.3.3
release.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-19 13:08

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, applied as main.c 1.83. Some systems
don't have strerror, which I also took into account.

----------------------------------------------------------------------

Comment By: Danny Yoo (dyoo)
Date: 2004-08-19 00:24

Message:
Logged In: YES 
user_id=49843

Modified the patch to more closely match error output from
Python.  Now prints "[Errno %d]" as well as the strerror().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011822&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 13:32:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 13:32:44 2004
Subject: [Patches] [ python-Patches-900727 ] Add Py_InitializeEx to allow
	embedding without signals.
Message-ID: 

Patches item #900727, was opened at 2004-02-19 23:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900727&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dave Wilson (dmw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Py_InitializeEx to allow embedding without signals.

Initial Comment:
Here is a patch to allow initialization of Python
without installing the signal handlers. This is useful
in some/many situations.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-19 13:32

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

init.tex 1.20
pythonrun.h 2.64
NEWS 1.1105
pythonrun.c 2.208


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900727&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 13:36:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 13:36:27 2004
Subject: [Patches] [ python-Patches-695275 ] environment parameter for popen2
Message-ID: 

Patches item #695275, was opened at 2003-02-28 21:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695275&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: environment parameter for popen2

Initial Comment:
The patch provides a way to specify the environment for
the subprocess run by the popen2, popen3 and popen4
functions in the popen2 module on platforms that use
the Popen3 class. It does that by adding this parameter
to the __init__ method of Popen3 and the popenN
functions calling execvpe in _run_child if the env
parameter was not None.

This patch obviously doesn't add this parameter on e.g.
Windows. AFAICT from posixmodule.c where popen is
implemented via CreateProcess on Windows it would be at
least theorectically possible to implement it on
Windows as well. I don't have the need nor the time for
that unfortunately.

Being able to specify the environment for the
subprocess in popen is very useful for e.g. running a
CGI from Zope. ZCGI for instance modifies os.environ so
that the subprocess inherits it but that cause problems
because other threads may occasionally see a modified
environment. This is particularly bad for the oracle
client libraries on Linux which require certain
environment settings.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-19 13:36

Message:
Logged In: YES 
user_id=21627

Can you please add changes to Doc/lib/libpopen2.tex as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=695275&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 13:41:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 13:41:55 2004
Subject: [Patches] [ python-Patches-546244 ] implementation of Text.dump
	method
Message-ID: 

Patches item #546244, was opened at 2002-04-19 20:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=546244&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: John Williams (johnw42)
Assigned to: Guido van Rossum (gvanrossum)
Summary: implementation of Text.dump method

Initial Comment:
This is a fairly robust implementation of the dump
command for the text widget. It supports all the
options of the underlying Tk command. This patch is
relative to version 2.2.1.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-19 13:41

Message:
Logged In: YES 
user_id=21627

Guido had already committed this as Tkinter.py 1.162, on
2002/04/23. Closing it as accepted.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-21 20:57

Message:
Logged In: YES 
user_id=31435

Guido, care to try this again?  Looks like you're the only one 
to try in 2 years!

----------------------------------------------------------------------

Comment By: John Williams (johnw42)
Date: 2002-04-22 21:06

Message:
Logged In: YES 
user_id=44174

What an embarassing mistake! I've attached a new version
that uses a callback function to build the result list
instead of trying to parse a string with Tcl quoting in it.
It seems to work correctly when there are spaces and other
magic characters in the results.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 20:07

Message:
Logged In: YES 
user_id=6380

A quick test suggets that you don't parse the dump output
correctly. I entered "The quick brown fox jumps over the
lazy dog.\n" into a text widget, and then called
t.dump("1.0", "2.0"). It returned the following garbage:

[('text', '{The', 'quick'), ('brown', 'fox', 'jumps'),
('over', 'the', 'lazy'), ('dog.}', '1.0', 'mark'),
('current', '1.44', 'mark'), ('anchor', '1.44', 'mark'),
('insert', '1.44', 'text'), ('{', '}', '1.44')]

It looks like you don't parse the curly braces at all.

Maybe you can find someone on c.l.py to help you fix this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=546244&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 16:08:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 16:18:39 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-19 09:08

Message:
Logged In: YES 
user_id=995755

Should we expect the user to search/replace the style sheet
in the generated HTML?  I'm on a simplification kick and
this would keep the API from getting bigger.  I'm inclined
to do the same for  title and headers so I could eliminate
them from the API.

I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date.  I'm
currently testing and updating the documentation.  Hope to
post it late tonight or tommorow.

If there is anything else that should be changed, now would
be a good time to speak up!

Thanks again for everyone's help.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-18 22:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 11:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 21:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 12:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 11:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 10:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 17:03:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 17:03:57 2004
Subject: [Patches] [ python-Patches-870286 ] make Demo/scripts/primes.py
	usable as a module
Message-ID: 

Patches item #870286, was opened at 2004-01-04 10:18
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470

Category: Demos and tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: make Demo/scripts/primes.py usable as a module

Initial Comment:
I wanted to find all primes between 1985 and 2005, and
found out that Demo/scripts/primes.py is not usable as
a module, because it unconditionally executes main().
This patch adds a 'if __name__ == "__main__"' block
around the execution of the main() function, so that
one can simply import primes and use
primes.primes(1985, 2005) in order to achieve what I
wanted to achieve.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-18 17:58

Message:
Logged In: YES 
user_id=469548

Gerrit, are you still interested in doing this? I'll just
check in this patch if not.

----------------------------------------------------------------------

Comment By: Gerrit Holl (gerrit)
Date: 2004-01-17 15:58

Message:
Logged In: YES 
user_id=13298

Hm, I don't think I have enough mathematical knowledge to go
'all the way', although some of the suggestions are doable.
I'll have a look at it next week (week of Jan-26). 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-12 00:44

Message:
Logged In: YES 
user_id=80475

If you're going to improve this one, consider going all the way.

* Modernize the code -- the current version reads like Cobol
* Stop building the sieve after sqrt(MAX) entries have been
found.  Possibly use islice() to check only the relevant
entries in the primes table.
* Change the API to:  prime x [n]  which finds the first n
(default 1) primes larger than x.  prime(10,3) --> [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  Thu Aug 19 17:10:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 17:11:06 2004
Subject: [Patches] [ python-Patches-1007068 ] baseinteger: abstract
	superclass for int and long
Message-ID: 

Patches item #1007068, was opened at 2004-08-11 03:20
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: baseinteger: abstract superclass for int and long

Initial Comment:
Quote from PEP-237
(http://www.python.org/peps/pep-0237.html):

"""
A new type, integer, may be introduced that is an
abstract base type of which both the int and long
implementation types are subclassed.  This is useful so
that programs can check integer-ness with a single test:

    if isinstance(i, integer): ...
"""

The patch implement the superclass for int and long
with name 'baseinteger'.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-08-19 11:10

Message:
Logged In: YES 
user_id=33168

Assuming Guido wanted this closed too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-19 02:08

Message:
Logged In: YES 
user_id=6380

I take it back. Few people on python-dev cared about this,
and there's at least one potential abuse (subclassing from
it won't do the right thing). It's also something that will
go away again in 3.0 (where there will be only one integral
type). Let's just by convention write isinstance(x,
(int,long)) when we really need it.

You may ask what about basestring? Its use case is similarly
weak, and I expect it to disappear in 3.0. Let's not repeat
the mistake.

So I'm rejecting this now. Sorry!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-13 10:43

Message:
Logged In: YES 
user_id=6380

+1

One suggestion: I'd add some words to the docs to recommend
*not* to use this for one's own integer-ish class. Instead,
subclassing from int or long is recommended, to avoid
confusion (since many built-in operations and extensions
accept only "genuine" integers, i.e. int or long or
subclasses thereof).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007068&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 17:14:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 17:14:22 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: 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: 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 Aug 19 17:42:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 17:42:17 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 10:42
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=1012280&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012280&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 17:44:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 17:45:13 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 10:42
Message generated for change (Comment added) made by beerfrick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012280&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
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: Ariel Arjona (beerfrick)
Date: 2004-08-19 10: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  Thu Aug 19 19:21:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 19:21:22 2004
Subject: [Patches] [ python-Patches-1011890 ] fix inspect.getsource breaking
	with line-continuation & more
Message-ID: 

Patches item #1011890, was opened at 2004-08-19 03:11
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: fix inspect.getsource breaking with line-continuation & more

Initial Comment:
The patch makes changes to inspect.py in two places:

* the pattern to match against functions at line 436 is
modified: lambdas should be matched even if not
preceded by whitespace, as long as "lambda" isn't part
of another word.

* the BlockFinder class is heavily modified. Changes are: 
  - checking for "def", "class" or "lambda" names
before setting self.started to True. Then checking the
same line for word characters after the colon (if the
colon is on that line). If so, and the line does not
end with a line continuation marker, raise EndOfBlock
immediately.
  - adding self.passline to show that the line is to be
included and no more checking is necessary on that
line. Since a NEWLINE token is not generated when a
line continuation marker exists, this allows getsource
to continue with these functions even if the following
line would not be indented.

The patch might be making a mess of the simple code,
and code such as code it now handles will probably not
be seen often. Still, it fixes the first bug shown in
"www.python.org/sf/769569".

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-19 19:21

Message:
Logged In: YES 
user_id=469548

Looks very good. I've made some small changes:

- Moved the __main__ section into a test_main() block for
running by regrtest.py
- Used the run_unittest function from test_support.py
- De-abbreviated some of the test methods
- Used comments instead of docstrings: unittest prints the
docstring of a test method instead of the name of the test
method when failing, making the failing method harder to find.

Apart from that, it looks like checkin-quality to me. Still,
it's kind of ugly to have a two separate files and two
separate methods for testing the same module, so I guess
that means I'll be converting test_inspect to unittest. I'll
try to work on that tonight and post it to
http://python.org/sf/736962 tomorrow. I'll merge these tests
into the new test_inspect after it's checked in.

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-08-19 03:25

Message:
Logged In: YES 
user_id=329382

BTW: inspect.py CVS HEAD passes three of the tests:
test_oll, test_tlli and test_onelinefunc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011890&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 21:02:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 21:02:36 2004
Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation
Message-ID: 

Patches item #599331, was opened at 2002-08-23 12:03
Message generated for change (Comment added) made by jriehl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 1
Submitted By: Jon Riehl (jriehl)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 269 Implementation

Initial Comment:
The following are files for the implementation of PEP
269.  The primary changes to the core involve moving
required pgen modules from the pgen only module list to
the Python library module list in Makefile.pre.in. 
Some of the modules required better memory allocation
and management and the corresponding deallocators are
in the Python extension module (maybe these should be
moved into the pgen modules in Parser).

Initially included are two implementations.  The first
is a basic implementation that follows the PEP API more
or less.  The second (currently unfinished)
implementation provides a more object oriented
interface to the extension module.

Please note there are some commented out modifications
to setup.py as I was unable to build the extension
module(s) automagically.  For some reason the linker I
was using (on a BSD box) complained that it couldn't
find the _Py_pgen symbol, even though I verified its
existence in the new Python library.  Maybe it is
checking against an older Python library on the system?

Things to be done (as of initial submission) include
resolving on a single interface, documenting the one
true interface, and finishing any unimplemented
routines (such as are found in the OO implementation).

In the final integration, a pgenmodule.c file should be
added to the Modules directory in the main distribution.

----------------------------------------------------------------------

>Comment By: Jon Riehl (jriehl)
Date: 2004-08-19 14:02

Message:
Logged In: YES 
user_id=22448

It may not be super usable (I believe it is as usable as
pgen is, which is just usable enough to automate Python
parser generation), but I consider it finished.  The SVN URL
is now:

http://codespeak.net/svn/basil/trunk/basil/common/python/

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-18 22:57

Message:
Logged In: YES 
user_id=6380

FWIW, I *also* rewrote pgen in Python. Is the Pypy version
real? If so, I ma not have to publish my code (which is
owned by Elemental Security but if there's demand I can
attempt to open-source it).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 06:57

Message:
Logged In: YES 
user_id=21627

I have now marked the PEP as deferred, until some volunteer
picks it up again. I'm rejecting this patch (but left a
pointer in the PEP for reference).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-02 12:35

Message:
Logged In: YES 
user_id=21627

I was wondering what the possible next steps could be. With
your current analysis, it appears that
1. declare PEP 269 withdrawn
2. reject this patch
would be a possibility. I would want to keep this open only
if some volunteer would indicate interest in completing this
work.

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2003-11-01 17:20

Message:
Logged In: YES 
user_id=22448

I am to some extent.  I've done several wacky things, namely
putting the pgen extension module into my Basil project
(basically I think PEP 269 is dead), as well as re-written
pgen in "pure" Python (no C extension module calls)   The
pure Python pgen looks like it will be going into Pypy.  I
don't know if I am interested in the speed enough to warrant
serious analysis of the pgen C extension and the
segmentation fault Guido reported.  Let me know if you had
anything specific in mind.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-31 07:54

Message:
Logged In: YES 
user_id=21627

Jon, are you still interested in taking this further?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-17 10:12

Message:
Logged In: YES 
user_id=6380

I've checked in the changes to the parser and Makefile etc.
This means you should be able to distribute pgenmodule.c as
a clean extension to Python 2.3.

I've decided not to incorporate pgenmodule.c at this time.
There are three problems with it as I see it:

- The C coding style is really different, and makes it hard
to read: 2-space indents instead of tabs, spaces before left
parentheses in argument lists, space between * and name in
things like "PyObject * name", placement of curly braces,
reversal of arguments to comparisons (e.g. "NULL != x"), and
long strings of underscores in comments.

- The code isn't robust enough: I got a segfault (can't
remember after what sequence of events, sorry), and it
caused a SystemError (error return without exception set)
when the grammar file couldn't be read.

- The pgen API seems a bit strange -- some things that I
would expect to be methods of AST objects are functions in
the pgen module (even when a companion function *is* an AST
method).

- The unit test doesn't fit in the Python test framework.

- I cooked up a little expression grammar and tried to parse
a sample string, but all I got was exceptions. I guess I am
missing something, but there's no tutorial that explains me
how to do things (I was copying the code from test_pgen.py
which works :-( ).

Nevertheless, thanks for the work so far -- I'm sure at some
point pgen will be usable from Python!


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-14 15:44

Message:
Logged In: YES 
user_id=6380

OK, reading the README now...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-05 10:42

Message:
Logged In: YES 
user_id=6380

Closed. Jon, if you're still interested in this, upload
something new and reopen the patch (or I can do that).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 11:32

Message:
Logged In: YES 
user_id=6380

Lowering priority until Jon has his next version ready.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-12 23:35

Message:
Logged In: YES 
user_id=6380

Cool. Maybe I'll get to it, maybe not. :-(

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2002-09-12 13:04

Message:
Logged In: YES 
user_id=22448

Guido, as per my private message, I'll attempt to submit
another patch by the end of the month, pending resumption of
"work" on the 23rd.  Commitment of the memory allocation
patch is fine, and any future patches would be against the
updated pgen code (I don't have commit permissions, so
someone else will have to do this possibly.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-09 07:09

Message:
Logged In: YES 
user_id=6380

I looked a bit, and it's very raw - the author admits that.
Jon, are you still working on this? Do you have a more
polished version?

Maybe we can separate out the memory allocation patches and
commit these already? They don't break anything.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-03 14:44

Message:
Logged In: YES 
user_id=6380

I guess I'm going to hve to look at this to pronounce...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 22:20:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 22:20:38 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 (Tracker Item Submitted) made by Item Submitter
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.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012468&group_id=5470
From noreply at sourceforge.net  Thu Aug 19 23:10:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 19 23:15:59 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	subclass joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 18:03
Message generated for change (Settings changed) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
>Assigned to: Tim Peters (tim_one)
Summary: Return new string for single subclass joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:53

Message:
Logged In: YES 
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-12 08:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 22:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 00:17:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 00:17:43 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	subclass joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 03:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Tim Peters (tim_one)
Summary: Return new string for single subclass joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-19 17:17

Message:
Logged In: YES 
user_id=80475

The patch looks good, it compiles okay, and the test_suite
passes.

If Tim has no further issues, I will apply it.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 17:53

Message:
Logged In: YES 
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 17:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 17:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 07:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 00:28:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 00:30:01 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	subclass joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 04:03
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&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: Return new string for single subclass joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-19 18:28

Message:
Logged In: YES 
user_id=31435

Unassigned myself -- can't make time for this now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-19 18:17

Message:
Logged In: YES 
user_id=80475

The patch looks good, it compiles okay, and the test_suite
passes.

If Tim has no further issues, I will apply it.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 18:53

Message:
Logged In: YES 
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 18:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 18:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 08:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 09:39:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 09:39:51 2004
Subject: [Patches] [ python-Patches-1012740 ] cStringIO's truncate doesn't
Message-ID: 

Patches item #1012740, was opened at 2004-08-20 07:39
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=1012740&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: cStringIO's truncate doesn't

Initial Comment:
truncate on a writeable cStringIO doesn't reset the cursor,
and when another write occurs, the old data magically comes
back:

>>> io = cStringIO.StringIO()
>>> io.write('abc')
>>> io.truncate(0)
>>> io.write('xyz')
>>> io.getvalue()
'abcxyz'

Using the original StringIO module, the latter value is
'xyz', as expected. As far as I can tell, this can't be used
to crash the interpreter because cStringIO never shrinks its
buffer, so the old position is still in bounds. (It probably
should shrink its buffer, but that can be fixed later, if
desired, since it would not change the perceived behavior.)

Even though this introduces a user-visible change, it should
be safe to fix this for 2.4. Anyone that relies on this
wacky behavior already has it coming, and we're not even in
beta yet.

The patch includes a test case that used to succeed with
StringIO but fail with cStringIO. An update to NEWS is also
included since this does, after all, introduce a visible
change.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 10:12:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 10:12:43 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-20 03:12

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) added optional line wrapping using a wrapcolumn argument 
to make_file and make_table methods.
2) eliminated a number of optional arguments to simplify API 
(as discussed).
3) made everything protected (by naming convention) except 
for the public make_table and make_file methods (as 
discussed).

NOTE1

I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a month or so back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

NOTE2

I will not be monitoring emails or this patch from Saturday 
Aug21 thru Wednesday Aug25.  When I break my internet 
silence I'll see if I've blundered this update (unlikely because I 
tested it pretty well but none the less possible).  If 
everything went well I will be soliciting Python-Dev to try to 
get this in alpha3.  I need someone with checkin privledges to 
do it.  Should I be trying to gather more support for its 
inclusion or does this only need to be done to convince 
someone with checkin privledges to apply the patch?

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-19 09:08

Message:
Logged In: YES 
user_id=995755

Should we expect the user to search/replace the style sheet
in the generated HTML?  I'm on a simplification kick and
this would keep the API from getting bigger.  I'm inclined
to do the same for  title and headers so I could eliminate
them from the API.

I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date.  I'm
currently testing and updating the documentation.  Hope to
post it late tonight or tommorow.

If there is anything else that should be changed, now would
be a good time to speak up!

Thanks again for everyone's help.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-18 22:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 11:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 21:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 12:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 11:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 10:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 13:25:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 13:25:37 2004
Subject: [Patches] [ python-Patches-943206 ] Convert glob.glob to
	generator-based DFS
Message-ID: 

Patches item #943206, was opened at 2004-04-27 21:25
Message generated for change (Comment added) made by cben
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Convert glob.glob to generator-based DFS

Initial Comment:
`glob.glob()` currently calls itself recursively to
build a list of matches of the dirname part of the
pattern and then filters by the basename part.  This is
effectively BFS.  ``glob.glob('*/*/*/*/*/foo')`` will
build a huge list of all directories 5 levels deep even
if only a handful of them contain a ``foo`` entry.  A
generator-based recusion would never have to store
these list at once by implementing DFS.
This patch converts the `glob` function to an `iglob`
recursive generator .  `glob()` now just returns
``list(iglob(pattern))``.
I also cleaned up the code a bit (reduced duplicate
`has_magic()` checks and created a second `glob0`
helper func so that the main loop need not be duplicated).

This patch assumes patch 941486 adding
`os.path.lexists()` was applied; if not the lexists
calls will have to be adjasted.

Tests and docs patches included.


----------------------------------------------------------------------

>Comment By: Cherniavsky Beni (cben)
Date: 2004-08-20 14:25

Message:
Logged In: YES 
user_id=36166

Refreshed against current trunk (2.4a2+ 2004-08-20).
It's a forward patch -p0, at dist/src.  Again, it assumes
patch 941486  (glob-pathfix.diff version) had been applied;
if not s/lexists/exists/g but then neither version of 941486
will apply cleanly.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=943206&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 17:06:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 17:06:07 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: 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: 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  Fri Aug 20 17:14:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 17:14:59 2004
Subject: [Patches] [ python-Patches-1012740 ] cStringIO's truncate doesn't
Message-ID: 

Patches item #1012740, was opened at 2004-08-20 03:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: cStringIO's truncate doesn't

Initial Comment:
truncate on a writeable cStringIO doesn't reset the cursor,
and when another write occurs, the old data magically comes
back:

>>> io = cStringIO.StringIO()
>>> io.write('abc')
>>> io.truncate(0)
>>> io.write('xyz')
>>> io.getvalue()
'abcxyz'

Using the original StringIO module, the latter value is
'xyz', as expected. As far as I can tell, this can't be used
to crash the interpreter because cStringIO never shrinks its
buffer, so the old position is still in bounds. (It probably
should shrink its buffer, but that can be fixed later, if
desired, since it would not change the perceived behavior.)

Even though this introduces a user-visible change, it should
be safe to fix this for 2.4. Anyone that relies on this
wacky behavior already has it coming, and we're not even in
beta yet.

The patch includes a test case that used to succeed with
StringIO but fail with cStringIO. An update to NEWS is also
included since this does, after all, introduce a visible
change.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-20 11:14

Message:
Logged In: YES 
user_id=31435

Boosted priority because I think I've bumped into this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 17:39:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 17:39:34 2004
Subject: [Patches] [ python-Patches-941486 ] Fixes for bug 940578 (glob.glob
	on broken symlinks)
Message-ID: 

Patches item #941486, was opened at 2004-04-24 22:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Fixes for bug 940578 (glob.glob on broken symlinks)

Initial Comment:
This does minimal changes to fix the bug.
It implements a function similar to `os.path.exists()`
but using
`os.lstat()` that doesn't fail on broken symlinks. 
This function would more properly belong in `posix`. 
This patch is good if you want to avoid API changes,
e.g. for backporting the fix.
Test case and doc fix (to make the behavior on broken
symlinks clear) are included.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 17:39

Message:
Logged In: YES 
user_id=469548

Is there any problem with just using 'if
os.path.islink(pathname) or os.path.exists(pathname)'? It
passes your test and it avoids adding a new function to
os.path. I've attached a patch using this. I'll check it in
if you don't have a problem with this.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-27 11:35

Message:
Logged In: YES 
user_id=36166

Uploaded two fixes to glob-pathfix:

- Added ``lexists = exists`` to plat-riscos/riscospath.py
(forgot it previously).

- Switched to implementing `lexists` with `os.lstat` in
macpath.py.  It has a non-trivial `islink`, so it might need
it (or might not; I have no Mac access so I can't tell). 
Better safe than sorry (if somebody knows it's redudadnt,
feel  free to revert to  ``lexists = exists``...).

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-24 23:25

Message:
Logged In: YES 
user_id=36166

The second patch, glob-pathfix.diff, does the right thing by
adding `lexists` to `os.path` - it has no less right to be
there than `exists`.
It's implemented with `os.lstat()` in `posixpath`, alias to
`exists` in other `*path` modules.  **Please verify that
this is sufficient - it seems that no other platfrom has a
`os.lstat` that is not equivallent to `os.stat` but I can't
be sure.**

The glob.py bugfix then is a trivial  change from
``os.path.exists``
to ``os.path.lexists``.
Testcases and doc additions included.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 18:39:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 18:39:53 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: Raymond Hettinger (rhettinger)
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-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  Fri Aug 20 19:33:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 19:33:47 2004
Subject: [Patches] [ python-Patches-981773 ] crach link c++ extension by
	mingw
Message-ID: 

Patches item #981773, was opened at 2004-06-29 01:42
Message generated for change (Comment added) made by furrykef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandr Zamaraev (shura_zam)
Assigned to: Nobody/Anonymous (nobody)
Summary: crach link c++ extension by mingw

Initial Comment:
if cource of exttension module writen in C++
setup break and say:

cc -mno-cygwin -shared -s build\temp.win32-2.3
\Release\dybaseapi.o 
build\temp.win32-2.3\Release\..\src\btree.o 
build\temp.win32-2.3\Release\..\src\database.o 
build\temp.win32-2.3\Release\..\src\dybase.o 
build\temp.win32-2.3\Release\..\src\file.o 
build\temp.win32-2.3\Release\..\src\pagepool.o 
build\temp.win32-2.3\Release\dybaseapi.def 
-LC:\Lang\Python23\libs -LC:\Lang\Python23\PCBuild 
-lpython23 -o build\lib.win32-2.3\dybaseapi.pyd
error: command 'cc' failed: No such file or directory

I patch cygwinccompiler.py for resolve:

*** C:\Lang\Python23\work\Python-2.3.4
\Lib\distutils\cygwinccompiler.py	Mon Apr 14 
19:51:26 2003
--- C:\Lang\Python23\work\cygwinccompiler2.py
	Tue Jun 29 13:00:23 2004
***************
*** 108,113 ****
--- 108,114 ----
          # XXX optimization, warnings etc. should be 
customizable.
          self.set_executables(compiler='gcc -mcygwin -O -
Wall',
                               compiler_so='gcc -mcygwin -
mdll -O -Wall',
+                              compiler_cxx='g++ -mcygwin -O -
Wall',
                               linker_exe='gcc -mcygwin',
                               linker_so=('%s -mcygwin %s' %
                                          (self.linker_dll, 
shared_option)))
***************
*** 295,300 ****
--- 296,302 ----
  
          self.set_executables(compiler='gcc -mno-
cygwin -O -Wall',
                               compiler_so='gcc -mno-cygwin -
mdll -O -Wall',
+                              compiler_cxx='g++ -mno-cygwin -
O -Wall',
                               linker_exe='gcc -mno-cygwin',
                               linker_so='%s -mno-cygwin %s %
s'
                                          % (self.linker_dll, 
shared_option,


----------------------------------------------------------------------

Comment By: Kef Li Eric MARCVS X (furrykef)
Date: 2004-08-20 12:33

Message:
Logged In: YES 
user_id=536129

I do hope this patch is integrated. As it is, I'm going to
have to tell my users to patch distutils by hand...

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-07 09:29

Message:
Logged In: YES 
user_id=2772

Please attach your diff, rather than pasting it into the
text box.  The diff is hopelessly mangled, and cannot be
applied for testing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=981773&group_id=5470
From noreply at sourceforge.net  Fri Aug 20 20:31:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 20 20:32:00 2004
Subject: [Patches] [ python-Patches-1013055 ] Fix for duplicate attributes
	in generated HTML
Message-ID: 

Patches item #1013055, was opened at 2004-08-20 18:31
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=1013055&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brodie (leogah)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for duplicate attributes in generated HTML

Initial Comment:
The bottom navigation bar of many of the Python pages 
contains duplicated "rel" and "title" attributes, because 
make_nav_panel has side effects.   
 
Attached patch should remove the duplication, and reduce 
HTML validation errors. 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013055&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 08:11:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 08:11:34 2004
Subject: [Patches] [ python-Patches-1012740 ] cStringIO's truncate doesn't
Message-ID: 

Patches item #1012740, was opened at 2004-08-20 03:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: Tim Peters (tim_one)
Summary: cStringIO's truncate doesn't

Initial Comment:
truncate on a writeable cStringIO doesn't reset the cursor,
and when another write occurs, the old data magically comes
back:

>>> io = cStringIO.StringIO()
>>> io.write('abc')
>>> io.truncate(0)
>>> io.write('xyz')
>>> io.getvalue()
'abcxyz'

Using the original StringIO module, the latter value is
'xyz', as expected. As far as I can tell, this can't be used
to crash the interpreter because cStringIO never shrinks its
buffer, so the old position is still in bounds. (It probably
should shrink its buffer, but that can be fixed later, if
desired, since it would not change the perceived behavior.)

Even though this introduces a user-visible change, it should
be safe to fix this for 2.4. Anyone that relies on this
wacky behavior already has it coming, and we're not even in
beta yet.

The patch includes a test case that used to succeed with
StringIO but fail with cStringIO. An update to NEWS is also
included since this does, after all, introduce a visible
change.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-21 02:11

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-20 11:14

Message:
Logged In: YES 
user_id=31435

Boosted priority because I think I've bumped into this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 08:57:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 08:57:36 2004
Subject: [Patches] [ python-Patches-1012740 ] cStringIO's truncate doesn't
Message-ID: 

Patches item #1012740, was opened at 2004-08-20 03:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470

>Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Tim Peters (tim_one)
Summary: cStringIO's truncate doesn't

Initial Comment:
truncate on a writeable cStringIO doesn't reset the cursor,
and when another write occurs, the old data magically comes
back:

>>> io = cStringIO.StringIO()
>>> io.write('abc')
>>> io.truncate(0)
>>> io.write('xyz')
>>> io.getvalue()
'abcxyz'

Using the original StringIO module, the latter value is
'xyz', as expected. As far as I can tell, this can't be used
to crash the interpreter because cStringIO never shrinks its
buffer, so the old position is still in bounds. (It probably
should shrink its buffer, but that can be fixed later, if
desired, since it would not change the perceived behavior.)

Even though this introduces a user-visible change, it should
be safe to fix this for 2.4. Anyone that relies on this
wacky behavior already has it coming, and we're not even in
beta yet.

The patch includes a test case that used to succeed with
StringIO but fail with cStringIO. An update to NEWS is also
included since this does, after all, introduce a visible
change.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-21 02:57

Message:
Logged In: YES 
user_id=31435

Thanks -- nice work!  Accepted and checked in:

Lib/test/test_StringIO.py 1.18
Misc/NEWS 1.1107
Modules/cStringIO.c 2.49


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-21 02:11

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-20 11:14

Message:
Logged In: YES 
user_id=31435

Boosted priority because I think I've bumped into this too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012740&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 12:44:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 12:44:44 2004
Subject: [Patches] [ python-Patches-1011123 ] Bad URL encoding in
	SimpleHTTPServer directory listing
Message-ID: 

Patches item #1011123, was opened at 2004-08-18 03:12
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011123&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Niels Diepeveen (nielsdi)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Bad URL encoding in SimpleHTTPServer directory listing

Initial Comment:
The list_directory method of SimpleHTTPRequestHandler uses cgi.escape() to encode the filenames.
However, the HREF part should be encoded using urllib.quote(). This patch fixes that.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 12:44

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.22 of SimpleHTTPServer.py. Thanks for
the patch!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011123&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 13:11:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 13:11:18 2004
Subject: [Patches] [ python-Patches-997726 ] dircache fix;
	raise like os.listdir, plus optimization
Message-ID: 

Patches item #997726, was opened at 2004-07-26 00:21
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997726&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Henrik Holth Lunde (chlunde)
Assigned to: Nobody/Anonymous (nobody)
Summary: dircache fix; raise like os.listdir, plus optimization

Initial Comment:
I think it would be better if dircache.listdir acts
like os.listdir on missing 
directories; raise os.error

Additionally, I rewrote the logic so it's about 15%
faster.  If you remove 
the outer try-except-block which purges the cache for a
folder on a 
miss it's 30% faster. This makes if five times as fast
as os.listdir (with
my program).

Not sure if anybody cares about the speed, the thing I
was surprised
about was that dircache wasn't a drop-in replacement
for listdir.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 13:11

Message:
Logged In: YES 
user_id=469548

Could you take a look at the latest CVS revision? I think
rev 1.12 and patch #707167 already make dircache raise
os.error on missing directories. The optimization would be
interesting, but you should post a diff against latest CVS
(see http://python.org/dev/devfaq.html#how-to-make-a-patch)
instead of a replacement file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997726&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 13:19:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 13:20:00 2004
Subject: [Patches] [ python-Patches-933238 ] doctest: add a special
	(dedented) marker for blank lines
Message-ID: 

Patches item #933238, was opened at 2004-04-11 17:11
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=933238&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Edward Loper (edloper)
>Assigned to: Edward Loper (edloper)
Summary: doctest: add a special (dedented) marker for blank lines

Initial Comment:
A current limitation of doctest is that it can't handle 
output containing blank lines, since it uses blank 
lines to detect the end of the example.

This patch uses adds special "blank line marker" to 
mark blank lines in the expected output.  In order to 
distinguish this marker from actual output, it must be 
dedented such that it ends just before the doctest 
example's indentation.

Here's an example use, with BLANKLINE_MARKER set 
to "-" (as it is in the patch):

def _test_blankline_marker():
    r"""
    This test example uses BLANKLINE_MARKER to 
    signify a blank line:

        >>> print 'first line\n\nthis is after a blank line'
        first line
       -
        this is after a blank line
        >>> print 'trailing blanks can be marked too\n'
        trailing blanks can be marked too
       -
    """

If desired, BLANKLINE_MARKER could be changed to 
another string. (This is an option for the developers 
of doctest, *not* for users.) E.g., here's the same 
example with BLANKLINE_MARKER="BL>":

def _test_blankline_marker():
    r"""
    This test example uses BLANKLINE_MARKER to 
    signify a blank line:

        >>> print 'first line\n\nthis is after a blank line'
        first line
     BL>
        this is after a blank line
        >>> print 'trailing blanks can be marked too\n'
        trailing blanks can be marked too
     BL>
    """

In the patch, the indentation rules for 
BLANKLINE_MARKER are fairly strict: it must be 
dedented to end one character before the indentation 
defined by the doctest example's prompt (>>>).  
But if desired, we could relax this restriction, and say 
that it simply has to be dedented further than the 
prompt.  E.g., this would make the following legal (it 
currently is not):

def _test_blankline_marker():
    r"""
    This test example uses BLANKLINE_MARKER to 
    signify a blank line:

        >>> print 'first line\n\nthis is after a blank line'
        first line
    -
        this is after a blank line
        >>> print 'trailing blanks can be marked too\n'
        trailing blanks can be marked too
    -
    """

This patch is probably mutually exclusive with patch 
#932933 [1], since they both have the same goal: to 
allow blank lines in doctest output.  I thought of the 
other solution first, but I think I prefer this patch. 
Here's a comparison of pros and cons of this patch vs 
#932933.

  [+] it doesn't need a special option to turn it on
  [+] it handles trailing blank lines
  [+] it won't break external tools like epytext and
      restructuredtext that look for doctest blocks.
  [-] the user must manually add blank line markers.

[1] 

The patch was made avainst revision 1.33 of 
doctest.py.  If this patch looks good, I'd be happy to 
write a patch for docs & test cases.




----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 13:19

Message:
Logged In: YES 
user_id=469548

Edward, it seems like recent doctest checkins have addressed
this, so I'm closing this. Please reopen if I'm mistaken.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-05-31 20:56

Message:
Logged In: YES 
user_id=21627

This patch is incomplete: It lacks changes to the
documentation (libdoctest.tex) and to the test suite
(test_libdoctest.tex).

Pasting examples into the patch submission is futile: they
are lost once the patch is accepted. So if you think users
of your patch should know them, you should incorporate them
into your patch - if not in the documentation, then perhaps
in the Demo directory.

Please submit a single patch file containing all changes.

SF has not stripped the indentation; if you look at the HTML
source, you'll see it is still there. However, in HTML,
indentation is stripped by the web browsers. That is one
reason why the submission guidelines say not to include the
code in the description.

----------------------------------------------------------------------

Comment By: Edward Loper (edloper)
Date: 2004-04-11 17:18

Message:
Logged In: YES 
user_id=195958

I just noticed that sourceforge strips leading whitespace 
from every line.  (Why does it do that?)  You should be 
able to reconstruct what the examples should look like 
from the text, but if not, here's the first example with 
leading spaces replaced by periods:

def _test_blankline_marker():
....r"""
....This test example uses BLANKLINE_MARKER to signify
....a blank line:
....
........>>> print 'first line\n\nthis is after a blank line'
........first line
.......-
........this is after a blank line
........>>> print 'trailing blanks can be marked too\n'
........trailing blank lines can be marked too
.......-
...."""


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=933238&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 13:46:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 13:46:18 2004
Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug
	925628)
Message-ID: 

Patches item #934356, was opened at 2004-04-13 19:02
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help on re-exported names (bug 925628)

Initial Comment:
help(module) only provides help on classes and functions 
that were first defined within the module.  For wrapper 
modules (like re), or partially-in-C modules (like socket)
this is not helpful.

The following patch changes pydoc(module) to document 
exactly the names listed in __all__, with a fallback to the 
current choices if __all__ is not defined.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 13:46

Message:
Logged In: YES 
user_id=469548

Right now all four hunks of the patch are failing for me
(probably because of #969938, which fixes part of the
problem). Could you update the patch to CVS HEAD and assign
to me afterwards? I'll take a good look at it then.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-16 22:23

Message:
Logged In: YES 
user_id=764593

Replacing with an improved version.  This is a diff to CVS 
head; users of Python 2.3 would have to either change the 
line numbers or also replace collections.deque.  (Setting deque 
to list was enough to allow testing.)

[Original patch had a problem with normal modules, but the 
exception was caught at a higher level, and *something* 
returned, so I didn't notice it at first.]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 13:53:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 13:53:20 2004
Subject: [Patches] [ python-Patches-870807 ] optparse int,
	long types support binary, octal and hex forma
Message-ID: 

Patches item #870807, was opened at 2004-01-05 11:18
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870807&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Martin v. L?wis (loewis)
Summary: optparse int, long types support binary, octal and hex forma

Initial Comment:
Hello,

I've added support for binary, octal and hexa number
with the "int" and "long" types.
binary : 0b10 (= 2)
octal : 010 (= 8)
hexa: 0x10 (= 16)

Diff for optparse.py and test_optparse.py attached.

Miki.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 13:53

Message:
Logged In: YES 
user_id=469548

optparse.py is automatically generated from the Optik source
code, so you should file this against the Optik project
(http://sf.net/projects/optik/) instead of here. 

Still, liboptparse.tex isn't in the Optik project, so this
should be kept open as well.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-02-01 12:31

Message:
Logged In: YES 
user_id=358087

Attached.
Please check it, English is *not* my native language.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-31 13:39

Message:
Logged In: YES 
user_id=21627

Can you please provide a patch for Doc/lib/liboptparse.tex
as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870807&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 14:31:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 14:31:44 2004
Subject: [Patches] [ python-Patches-880621 ] incorrect end-of-message
	handling in mailbox.BabylMailbox
Message-ID: 

Patches item #880621, was opened at 2004-01-20 16:15
Message generated for change (Settings changed) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880621&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: KAJIYAMA, Tamito (kajiyama)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: incorrect end-of-message handling in mailbox.BabylMailbox

Initial Comment:
The mailbox.BabylMailbox class does not handle end of
message correctly.
The last message in a mailbox ends in '\037' instead of
'\037\014\n'
(i.e. FF and LF do not exist at the end of the
mailbox).  However, the
class in question does not take this special case into
account, so that
application programs get '\037' as the last line of the
last message.
Following is a simple fix of this bug:

--- mailbox.py.orig	Tue Jan 20 23:10:32 2004
+++ mailbox.py	Tue Jan 20 23:08:17 2004
@@ -263,7 +263,7 @@
             line = self.fp.readline()
             if not line:
                 return
-            if line == '\037\014\n':
+            if line == '\037\014\n' or line == '\037':
                 self.fp.seek(pos)
                 return

The bug is in Python 2.3.3 and probably all of older
versions.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 14:31

Message:
Logged In: YES 
user_id=469548

Checked in as  rev 1.44 of mailbox.py. Thanks for the patch!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880621&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 14:55:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 14:55:56 2004
Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to
	os.path.abspath()
Message-ID: 

Patches item #677890, was opened at 2003-01-31 02:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Klanderman (gregklanderman)
Assigned to: Nobody/Anonymous (nobody)
Summary: add optional CWD argument to os.path.abspath()

Initial Comment:
I would like to add an optional second argument to
os.path.abspath() to allow specifying the directory
with respect to which the path should be made
absolute.  This would be much like the optional second
argument of the expand-file-name function in emacs:

(expand-file-name NAME &optional DEFAULT-DIRECTORY)

The patch is against python 2.2.2.  I am running RH 6.3
linux 
but that should not matter.

thanks
Greg Klanderman
gak@klanderman.net


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 14:55

Message:
Logged In: YES 
user_id=469548

Well, depends on what you mean by 'support'. I don't think
anyone seriously objects, but there doesn't seem to be
anyone who really cares either. That usually means that if
you care enough to create a complete implementation
(including tests and documentation changes) yourself, the
patch will be accepted. So please submit a new patch if you
do care enough.

----------------------------------------------------------------------

Comment By: Greg Klanderman (gregklanderman)
Date: 2003-02-05 19:09

Message:
Logged In: YES 
user_id=698972

i can submit a patch for those other versions of abspath. 
but i'd rather know whether there is support for this change
before doing that.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-02-05 11:16

Message:
Logged In: YES 
user_id=357491

And don't forget riscospath.py found in the plat-risc directory in Lib in the source distribution.  =)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-02-05 11:06

Message:
Logged In: YES 
user_id=357491

What about ntpath.py and os2emxpath.py?

----------------------------------------------------------------------

Comment By: Greg Klanderman (gregklanderman)
Date: 2003-01-31 02:28

Message:
Logged In: YES 
user_id=698972

sorry, trying again to attach the patch..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470
From noreply at sourceforge.net  Sat Aug 21 17:14:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 21 17:14:48 2004
Subject: [Patches] [ python-Patches-1009373 ] (bug 1005936) textunderscore
	python.sty fix
Message-ID: 

Patches item #1009373, was opened at 2004-08-14 19:57
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009373&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dave Watson (docwatson)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: (bug 1005936) textunderscore python.sty fix

Initial Comment:
(bug 1005936)

In pdf bookmark links, \_ was being converted to
'protect hbox.....55ex', instead of being inserted
verbatim.   This fix, taken from hyperref, changes \_
to {\string_} so that it is output correctly in the
bookmarks file.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-08-21 11:14

Message:
Logged In: YES 
user_id=33168

I can't test with acrobat, but it doesn't break on Unix. 
That's good enough for  me since Jeff says it fixed his problem.

Thank you both.

Checked in as:
 * Doc/texinputs/python.sty 1.110
 * Misc/NEWS 1.1108

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-14 21:57

Message:
Logged In: YES 
user_id=2772

This works for me.  I rebuilt html and pdf versions of the
documentation, and everything looked fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009373&group_id=5470
From sculptsbernini at verizon.net  Sat Aug 21 21:18:13 2004
From: sculptsbernini at verizon.net (Nilgun Chavez)
Date: Sat Aug 21 23:18:01 2004
Subject: [Patches] WHAT W0MEN DES1lRE
Message-ID: 

An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20040822/e365424c/attachment.htm
From noreply at sourceforge.net  Sun Aug 22 00:19:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 00:19:33 2004
Subject: [Patches] [ python-Patches-941486 ] Fixes for bug 940578 (glob.glob
	on broken symlinks)
Message-ID: 

Patches item #941486, was opened at 2004-04-24 23:23
Message generated for change (Comment added) made by cben
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Fixes for bug 940578 (glob.glob on broken symlinks)

Initial Comment:
This does minimal changes to fix the bug.
It implements a function similar to `os.path.exists()`
but using
`os.lstat()` that doesn't fail on broken symlinks. 
This function would more properly belong in `posix`. 
This patch is good if you want to avoid API changes,
e.g. for backporting the fix.
Test case and doc fix (to make the behavior on broken
symlinks clear) are included.


----------------------------------------------------------------------

>Comment By: Cherniavsky Beni (cben)
Date: 2004-08-22 01:19

Message:
Logged In: YES 
user_id=36166

This will indeed fix the bug.  The only technical problem is that it is less efficient (does two stat calls, trying ``lstat(path)`` does one).
The point of adding a new library function was that IMHO it would be no less useful on average than the behavior of `os.path.exists()`.  There must be other code which could benefit from an obvious way to do it.
Also, having two "sister" functions would encourage people to think which behavior for symlinks is more appropriate in their case, instead of automatically using  `os.path.exists()`.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 18:39

Message:
Logged In: YES 
user_id=469548

Is there any problem with just using 'if
os.path.islink(pathname) or os.path.exists(pathname)'? It
passes your test and it avoids adding a new function to
os.path. I've attached a patch using this. I'll check it in
if you don't have a problem with this.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-27 12:35

Message:
Logged In: YES 
user_id=36166

Uploaded two fixes to glob-pathfix:

- Added ``lexists = exists`` to plat-riscos/riscospath.py
(forgot it previously).

- Switched to implementing `lexists` with `os.lstat` in
macpath.py.  It has a non-trivial `islink`, so it might need
it (or might not; I have no Mac access so I can't tell). 
Better safe than sorry (if somebody knows it's redudadnt,
feel  free to revert to  ``lexists = exists``...).

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-25 00:25

Message:
Logged In: YES 
user_id=36166

The second patch, glob-pathfix.diff, does the right thing by
adding `lexists` to `os.path` - it has no less right to be
there than `exists`.
It's implemented with `os.lstat()` in `posixpath`, alias to
`exists` in other `*path` modules.  **Please verify that
this is sufficient - it seems that no other platfrom has a
`os.lstat` that is not equivallent to `os.stat` but I can't
be sure.**

The glob.py bugfix then is a trivial  change from
``os.path.exists``
to ``os.path.lexists``.
Testcases and doc additions included.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470
From jccarv at hotmail.com  Sun Aug 22 02:31:24 2004
From: jccarv at hotmail.com (John Stovas)
Date: Sun Aug 22 02:31:26 2004
Subject: [Patches] Olimpics
Message-ID: <20040822003125.531361E4003@bag.python.org>

An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20040821/7e0be9ce/attachment.htm
From noreply at sourceforge.net  Sun Aug 22 07:34:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 07:34:22 2004
Subject: [Patches] [ python-Patches-1013667 ] Cleanup Peepholer Output
Message-ID: 

Patches item #1013667, was opened at 2004-08-22 00:34
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=1013667&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Michael Hudson (mwh)
Summary: Cleanup Peepholer Output

Initial Comment:
Makes the peepholer output more compact, more readable,
and a bit faster.  Also saves a bit of space in pyc files.

* Uses NOPs instead of JMP+3 or JMP+2.
* Then, makes a pass to eliminate the NOPs (which
entails re-aligning the jump targets and linenotab).
* Add a transform to get rid of the unnecessary Return
Nones followed by another Return in the same block.
* Fixed the overflow test (codelen < 65000) to coerce
codelen to unsigned before the check.

Michael, I would appreciate it if you could give this a
second look just to make sure before I check it in.  I
would like it to go in well before the next alpha.  The
patch passes the test suite, runs all my own apps, and
has run on my machine for about a week with any issues.
If you don't have time to give it a once over, please
assign to Armin.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 08:50:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 08:50:17 2004
Subject: [Patches] [ python-Patches-870807 ] optparse int,
	long types support binary, octal and hex forma
Message-ID: 

Patches item #870807, was opened at 2004-01-05 11:18
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870807&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
>Assigned to: Greg Ward (gward)
Summary: optparse int, long types support binary, octal and hex forma

Initial Comment:
Hello,

I've added support for binary, octal and hexa number
with the "int" and "long" types.
binary : 0b10 (= 2)
octal : 010 (= 8)
hexa: 0x10 (= 16)

Diff for optparse.py and test_optparse.py attached.

Miki.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 08:50

Message:
Logged In: YES 
user_id=21627

Ok, assigning this to Greg for consideration.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 13:53

Message:
Logged In: YES 
user_id=469548

optparse.py is automatically generated from the Optik source
code, so you should file this against the Optik project
(http://sf.net/projects/optik/) instead of here. 

Still, liboptparse.tex isn't in the Optik project, so this
should be kept open as well.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-02-01 12:31

Message:
Logged In: YES 
user_id=358087

Attached.
Please check it, English is *not* my native language.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-31 13:39

Message:
Logged In: YES 
user_id=21627

Can you please provide a patch for Doc/lib/liboptparse.tex
as well?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870807&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 12:55:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 12:55:25 2004
Subject: [Patches] [ python-Patches-941486 ] Fixes for bug 940578 (glob.glob
	on broken symlinks)
Message-ID: 

Patches item #941486, was opened at 2004-04-24 22:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Fixes for bug 940578 (glob.glob on broken symlinks)

Initial Comment:
This does minimal changes to fix the bug.
It implements a function similar to `os.path.exists()`
but using
`os.lstat()` that doesn't fail on broken symlinks. 
This function would more properly belong in `posix`. 
This patch is good if you want to avoid API changes,
e.g. for backporting the fix.
Test case and doc fix (to make the behavior on broken
symlinks clear) are included.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-22 12:55

Message:
Logged In: YES 
user_id=469548

Hmm, it _is_ less efficient. I also looked through the
standard library and found another two modules which could
probably use this (tarfile.py and tempfile.py), so lexists
seems mildly useful after all. I'll ask on python-dev for
approval.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-08-22 00:19

Message:
Logged In: YES 
user_id=36166

This will indeed fix the bug.  The only technical problem is that it is less efficient (does two stat calls, trying ``lstat(path)`` does one).
The point of adding a new library function was that IMHO it would be no less useful on average than the behavior of `os.path.exists()`.  There must be other code which could benefit from an obvious way to do it.
Also, having two "sister" functions would encourage people to think which behavior for symlinks is more appropriate in their case, instead of automatically using  `os.path.exists()`.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 17:39

Message:
Logged In: YES 
user_id=469548

Is there any problem with just using 'if
os.path.islink(pathname) or os.path.exists(pathname)'? It
passes your test and it avoids adding a new function to
os.path. I've attached a patch using this. I'll check it in
if you don't have a problem with this.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-27 11:35

Message:
Logged In: YES 
user_id=36166

Uploaded two fixes to glob-pathfix:

- Added ``lexists = exists`` to plat-riscos/riscospath.py
(forgot it previously).

- Switched to implementing `lexists` with `os.lstat` in
macpath.py.  It has a non-trivial `islink`, so it might need
it (or might not; I have no Mac access so I can't tell). 
Better safe than sorry (if somebody knows it's redudadnt,
feel  free to revert to  ``lexists = exists``...).

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-24 23:25

Message:
Logged In: YES 
user_id=36166

The second patch, glob-pathfix.diff, does the right thing by
adding `lexists` to `os.path` - it has no less right to be
there than `exists`.
It's implemented with `os.lstat()` in `posixpath`, alias to
`exists` in other `*path` modules.  **Please verify that
this is sufficient - it seems that no other platfrom has a
`os.lstat` that is not equivallent to `os.stat` but I can't
be sure.**

The glob.py bugfix then is a trivial  change from
``os.path.exists``
to ``os.path.lexists``.
Testcases and doc additions included.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 17:39:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 17:39:54 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 (Tracker Item Submitted) made by Item Submitter
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: Open
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. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013835&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 17:55:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 17:55:15 2004
Subject: [Patches] [ python-Patches-977553 ] Speed up EnumKey call
Message-ID: 

Patches item #977553, was opened at 2004-06-22 10:22
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Garth Bushell (garth42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Speed up EnumKey call

Initial Comment:
This patch removes the RegQueryInfoKey call and
replaces it with a call to EnumKeyEx. This greatly
speeds up this call. 

The script below times 

python 2.3              5531 89.7130000591
python 2.4 +patch   5531 0.0469999313354

start = time.time()
i = 0
try:
  while 1:
    _winreg.EnumKey(_winreg.HKEY_CLASSES_ROOT, i)
    i += 1
except WindowsError:
  pass
print i, time.time() - start


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-26 07:31

Message:
Logged In: YES 
user_id=21627

Also, please follow the Python style guide for C code, PEP
7. In particular:
- use tabs for indentation, with a tab being worth 8 spaces
- omit spaces after opening and before closing parens
- put the opening brace of a code block on the same line as
the keyword


----------------------------------------------------------------------

Comment By: Garth Bushell (garth42)
Date: 2004-07-14 11:12

Message:
Logged In: YES 
user_id=45280

mmangino: 

Yes you're correct it should be 256 in both cases. Doh! I'll
attach a new patch in a while. but It's easy to mmodify the
patch and up the linit to 256

theller:

The advantage of the latter is it returns the Length of the
string returned so we can pass it straight back to the
string creation funtion in python without a strlen.

also the SDK says this....

Note  This function is provided only for compatibility with
16-bit versions of Windows. Applications should use the
RegEnumKeyEx function.



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-14 10:54

Message:
Logged In: YES 
user_id=11105

I'm curious: Why did you replace RegEnumKey with
RegEnumKeyEx? Are there any advantages of the latter?

----------------------------------------------------------------------

Comment By: Mike Mangino (mmangino)
Date: 2004-07-14 09:12

Message:
Logged In: YES 
user_id=74879

This looks good to me, but I think the buffer size is off by
one. I read the SDK to say tha they key can be 255
characters. That means you need to allocate 256 characters
to allow for the null terminator. Could you create a test
case for a max length registry key?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=977553&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:08:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:08:38 2004
Subject: [Patches] [ python-Patches-1009389 ] Non-ascii in non-unicode
	__credits__ in Lib/pydoc.py
Message-ID: 

Patches item #1009389, was opened at 2004-08-15 03:35
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Non-ascii in non-unicode __credits__ in Lib/pydoc.py

Initial Comment:
There are non-ASCII chars in pydoc.__credits__ (the
"o/" in "Mynd you, mo/o/se bites Kan be pretty
nasti...").  In 2.3, a locale declaration of Latin-1
was added to pydoc.py.  So now Python does not complain
-- but a string object (carrying no encoding info) with
Latin-1 bytes is still created and anynoby running in a
non-Latin-1 locale will not interpret the string correctly.
The patch fixes it by making pydoc.__credits__ a
Unicode string.  *Note that this may break code* that
prints pydoc.__credits__ (in locales that can't encode
it) or otherwise assumes it's a string.  Not that such
code exists anywhere...
Wait, ``import pydoc; help(pydoc)`` in "C" locale now
crashes !  This is too ironic, IMHO, *don't
commit* until pydoc learns to handle unicode robustly...


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:08

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as pydoc.py 1.96.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009389&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:15:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:16:32 2004
Subject: [Patches] [ python-Patches-997284 ] Allow pydoc to work with XP
	Themes (.manifest file)
Message-ID: 

Patches item #997284, was opened at 2004-07-25 00:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow pydoc to work with XP Themes (.manifest file)

Initial Comment:
In Python 2.3.4, if you run pydoc -g under Windows XP
when one of the special XP theme manifest files has
been defined for python.exe or pythonw.exe, pydoc will
cause an access violation when it closes.  One solution
is obviously to get rid of the manifest files, but
wxPython installs them by default and apps written with
it work without a problem.  So it would be nice if
pydoc would also work, and it turns out it didn't take
a big change.  Attached is a patch which fixes the
problem (at least on my system).  I noticed that idle
did not have the access violation problem, and so
copied what it does in PyShell.main.

It might be better to introduce a more general fix for
Tkinter.  The problem seems to be that Uxtheme.dll
frees up some global data before all the windows have
called CloseThemeData (at app shutdown).  The AV seems
to happen when a call to CloseThemeData (presumably in
response to a WM_DESTROY message) passes a bad pointer
to RtlEnterCriticalSection.  Anyway, it seems that if
you get the window handles destroyed earlier in
shutdown, the problem is fixed.  Perhaps there is some
way to provide the Tkinter module with an atexit
handler which would destroy any existing widgets?


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:15

Message:
Logged In: YES 
user_id=21627

This is quite an obscure problem, so I added a comment an
committed it as pydoc.py 1.86.8.3 and 1.97, NEWS 1.831.4.144.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:17:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:17:14 2004
Subject: [Patches] [ python-Patches-997768 ] LC_CTYPE locale and strings
Message-ID: 

Patches item #997768, was opened at 2004-07-26 03:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997768&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Pekka Pessi (ppessi)
Assigned to: Nobody/Anonymous (nobody)
Summary: LC_CTYPE locale and strings

Initial Comment:
It would be nice to get access to complete
locale-specific ctype information:

iscntrl()
isgraph()
isprint()
ispunct()

Also, the string.uppercase and string.lowercase depend
on LC_CTYPE locale. The string module has two other
members that could depend on LC_CTYPE,
string.punctuation and string.printable.

The current docs (in
http://www.python.org/doc/2.3.4/lib/module-string.html)
on string.printable is misleading, as string.printable
is not changed after LC_CTYPE locale changes, and it is
always
printable = digits + ascii_letters + punctuation +
whitespace

My approach is to create string.printable and
string.punctuation based on locale information, just
like string.uppercase and string.lowercase is done, and
add string.ascii_punctuation and string.ascii_printable
for the C locale values.

Patch containing proposed changes in stringobject,
string and _locale modules attached. No tests nor
changes to the docs, sorry.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:17

Message:
Logged In: YES 
user_id=21627

I personally don't see a need for these functions. As the
submitter cannot explain the need, either, I'm rejecting the
patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-26 14:58

Message:
Logged In: YES 
user_id=21627

Why do you need these functions?

It is convention that the Unicode type provides the same or
more methods, can you provide a patch that has a meaningful
definition for these methods for Unicode strings?

Reclassifying issue as a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997768&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:23:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:23:04 2004
Subject: [Patches] [ python-Patches-1000267 ] A BSD-style wait4
	implementation
Message-ID: 

Patches item #1000267, was opened at 2004-07-29 20:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: chads (cjschr)
Assigned to: Nobody/Anonymous (nobody)
Summary: A BSD-style wait4 implementation

Initial Comment:
A BSD-style wait4 implementation.

Using existing code from the posixmodule.c and
resource.c files,
I threw together a patch that implements the wait4
function.

This function is similar to waitpid, but it also
returns usage information
about the child process.

wait4(pid, options) -> (pid, status, rusage)

It works for me on RedHat Linux 9 and FreeBSD 4.5 boxes
using
Python-2.3.4.

The patch may need some fine tuning.

Thanks
Chad

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:23

Message:
Logged In: YES 
user_id=21627

struct rusage is already defined in
Modules/resourcemodule.c. It would be good if there was only
a single definition of the type object.

To achieve this, resourcemodule.c should expose a C API (e.g. 

  PyObject *PyResource_FromResource(struct rusage*)

). This should be put into a CObject, which should be
published through the module; then posixmodule should import
resource when wait4 is called for the first time.

Alternative, wait4 could be added to resourcemodule.c entirely.

Yet another alternative, on top of this approach,
posixmodule and/or os.py could provide their own definition
of wait4 which delegates to resource.wait4 on first usage.


----------------------------------------------------------------------

Comment By: chads (cjschr)
Date: 2004-08-13 21:00

Message:
Logged In: YES 
user_id=1093928

Added a test suite and an example of using wait4.  Feedback
is welcome.
Thanks.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-08-04 23:53

Message:
Logged In: YES 
user_id=2772

You should also add code to the test suite to test wait4
when it is available.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1000267&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:28:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:28:57 2004
Subject: [Patches] [ python-Patches-1013055 ] Fix for duplicate attributes
	in generated HTML
Message-ID: 

Patches item #1013055, was opened at 2004-08-20 13:31
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013055&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Brodie (leogah)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fix for duplicate attributes in generated HTML

Initial Comment:
The bottom navigation bar of many of the Python pages 
contains duplicated "rel" and "title" attributes, because 
make_nav_panel has side effects.   
 
Attached patch should remove the duplication, and reduce 
HTML validation errors. 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013055&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:30:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:30:18 2004
Subject: [Patches] [ python-Patches-970288 ] Fix for #876637 - Random stack
	corruption from socketmodule
Message-ID: 

Patches item #970288, was opened at 2004-06-10 13:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Troels Walsted Hansen (troels)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for #876637 - Random stack corruption from socketmodule

Initial Comment:
Here's a patch to convert socketmodule to use poll()
for the timeout handling.

ifdefs and includes have been copied from selectmodule,
so I believe they should be correct for all platforms.

Compiled and tested on Linux (RH73).


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:30

Message:
Logged In: YES 
user_id=21627

While the patch is good as it stands, it is also incomplete:
If poll(2) is not available, it might still overrun the
FD_SETSIZE. I think there should be another return value
from internal_select (-1), indicating an internal error. A
Python RuntimeError should be set in this case. Callers
should check for -1, and return immediately.

Are you willing to extend the patch in that direction?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:32:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:32:38 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-04 16:23
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2004-08-22 09:32

Message:
Logged In: YES 
user_id=971153

I am attaching a new version of the patch.

In addition to issues raised earlier the v1 version of patch
had a couple of other problems:

1. funcname based breakpoints got a wrong hit statistics
(hit counter was incremented on every effective() call,
which happened for every line of a function with a funcname
bkpt)

2. If a user set a bkpt via line number at def statement
(this is probably quite rare, but still possible) , then pdb
would stop at every line of that function when the function
is called

To fix these I had to move most of funcname handling logic
from break_here() into a separate function
(bdb.checkfuncname) and call it from bdb.effective()

Changes in the new version include: 

1. Fix the issues with statistics and bkpts at def stmt

2. Fix a doc line of checkline()

3. Rename .breakingline into .func_first_executable_line

4. Comment fixes


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-14 20:30

Message:
Logged In: YES 
user_id=971153

Ok, I'll submit an updated patch hopefully by the end of the
next week (I will be out of town for the next few days).

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 03:40

Message:
Logged In: YES 
user_id=469548

"Well, I am not sure: func_firstlineno causes a wrong
association with co_firstlineno (while these are almost
never the same)."

Ah, I misread the patch there. How about
func_first_executable_lineno (or something like that)? Or am
I off-base again?

"Would the following be better?"

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 
"

Yes. I was just having a bit of a hard time following your
patch. I think this is clearer.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-13 12:24

Message:
Logged In: YES 
user_id=971153


>- The checkline() docstring needs to be updated.
>- Try not to use multi-line comments after a statement
>(e.g.: 'return False #it's not a func call, but rather', etc.).

Ok, I can resubmit a patch for these two


>- For consistency, Breakpoint.breakingline should probably
>be called func_firstlineno.

Well, I am not sure: func_firstlineno causes a wrong
association with
co_firstlineno (while these are almost never the same).
Furthermore,
the  name ".breakingline" reflects the purpose: "a line
number where to break", while, "func_firstlineno" is totatly
neutral..
 

>- Moving the 'bp.breakingline=frame.f_lineno' statement into
>an else: branch of the 'if bp.breakingline and
>(bp.breakingline != frame.f_lineno)' statement would
>probably make the logic clearer.

Are you suggesting to replace:

                if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
                bp.breakingline=frame.f_lineno

with:

               if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
               else: 
                    bp.breakingline=frame.f_lineno

Why do you think it's better? It's definitely more verbose, has
an extra indentation level and looking through the code I
see a lot of code which looks like:

if  (....):
    return
foo
bar
without the else: branch


Would the following be better?

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 

Thus making it explicit that there are really 2 decisions
being made:
1) do we need to set the breakingline
2) do we need to break here


I don't have any strong feelings regarding these 2 issues,
just want to make sure that I understand the problem





----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 08:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:38:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:38:38 2004
Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module
Message-ID: 

Patches item #579435, was opened at 2002-07-10 05:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Lance Ellinghaus (ellinghaus)
Assigned to: A.M. Kuchling (akuchling)
Summary: Shadow Password Support Module

Initial Comment:
Attached is the spwd module. This module provides 
support for Shadow Passwords on Solaris 2.8. This 
compliments the nis and pwd modules. This is the only 
way to gain access to the encrypted passwords when 
using shadow passwords on Solaris.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:38

Message:
Logged In: YES 
user_id=21627

If we eventually want to support all the shadow passwort
APIs, we should make this a separate module - with that
approach, building spwd can might fail without causing a
failure to compile pwd.

Unfortunately, the patch is still incomplete: there is no
change to setup.py, and no documentation change. Are there
any volunteers interesting in completing it? If not, I'm
going to close it again. Anybody hunting for such a module
will still be able to find it.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-01-13 16:32

Message:
Logged In: YES 
user_id=11375

As it happens, I was hunting for Python shadow password support
and came across this patch.    The module isn't Solaris-specific, and 
would be necessary on Linux, too.
However, the interface for getting shadow passwords doesn't seem 
to be standardized; see http://www.unixpapa.com/incnote/passwd.
html for a list.  (The Single Unix spec doesn't seem to mention 
shadow passwords.)

One question is whether we want a new module for this, or if the 
functions should be in the existing pwd module.




----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-12 03:22

Message:
Logged In: YES 
user_id=33168

There doesn't seem to be much interest in this patch.  I
don't think it reaches a wide-enough audience, therefore,
I'm rejecting it.  If there is broader support (many people
are interested in seeing shadow password support in the
core), we can add it later.  I think it would be best to
provide this as a third-party module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470
From noreply at sourceforge.net  Sun Aug 22 18:44:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 22 18:44:26 2004
Subject: [Patches] [ python-Patches-562100 ] Installation database patch
Message-ID: 

Patches item #562100, was opened at 2002-05-29 23:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Installation database patch

Initial Comment:
The attached patch implements an installation database.

This patch is not yet correct; don't bother proofreading it 
yet.  I simply wanted to create a patch number so I could 
put it in PEP 262.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:44

Message:
Logged In: YES 
user_id=21627

What is the status of this patch? I see that the PEP still
has open issues. Who is championing this technology?

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-08 20:50

Message:
Logged In: YES 
user_id=3066

Just a note:  The install_db.py file is in Python's CVS, in
nondist/sandbox/pep262/.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-02-25 00:02

Message:
Logged In: YES 
user_id=3066

The attached patch implies the addition of the file
install_db.py, but does not include that file.  Please
attach that file to this patch report as well.

Thanks!

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-01-30 18:29

Message:
Logged In: YES 
user_id=11375

Reviving this patch.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-10-03 22:19

Message:
Logged In: YES 
user_id=139309

This should be brought back into play (patch finished, PEP heavily 
considered, or however that goes), the Package Manager effort 
going on in pythonmac-sig needs this functionality as part of 
distutils.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-10-24 21:13

Message:
Logged In: YES 
user_id=11375

Closing this patch with the withdrawal of PEP 262.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 00:18:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 00:18:44 2004
Subject: [Patches] [ python-Patches-1013667 ] Cleanup Peepholer Output
Message-ID: 

Patches item #1013667, was opened at 2004-08-22 00:34
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Cleanup Peepholer Output

Initial Comment:
Makes the peepholer output more compact, more readable,
and a bit faster.  Also saves a bit of space in pyc files.

* Uses NOPs instead of JMP+3 or JMP+2.
* Then, makes a pass to eliminate the NOPs (which
entails re-aligning the jump targets and linenotab).
* Add a transform to get rid of the unnecessary Return
Nones followed by another Return in the same block.
* Fixed the overflow test (codelen < 65000) to coerce
codelen to unsigned before the check.

Michael, I would appreciate it if you could give this a
second look just to make sure before I check it in.  I
would like it to go in well before the next alpha.  The
patch passes the test suite, runs all my own apps, and
has run on my machine for about a week with any issues.
If you don't have time to give it a once over, please
assign to Armin.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-22 17:18

Message:
Logged In: YES 
user_id=80475

Added a revision with better formatting and more tests.

This patch is open for whoever has time to look at it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 05:24:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 05:24:50 2004
Subject: [Patches] [ python-Patches-1014055 ] PEP 292 implementation
Message-ID: 

Patches item #1014055, was opened at 2004-08-22 23:24
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=1014055&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Raymond Hettinger (rhettinger)
Summary: PEP 292 implementation

Initial Comment:
Here's a patch implementing PEP 292.  It does /not/
include the string module reorganization.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014055&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 12:13:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 12:13:22 2004
Subject: [Patches] [ python-Patches-1014237 ] RobotFileParser.can_fetch
	return value
Message-ID: 

Patches item #1014237, was opened at 2004-08-23 19:13
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=1014237&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: RobotFileParser.can_fetch return value

Initial Comment:
Currently, RobotFileParser.can_fetch method returns two 
kinds of types(int and bool) and is not consistent.

More strictly, if a web site sets a robots.txt file, it 
returns 1/0. Otherwise, it returns boolean(True/False).

My change is to make can_fetch method return bool 
values in either case as documented in robotparser 
module.

# examples of can_fetch return values
>>> import robotparser
>>> rp = robotparser.RobotFileParser()
>>> rp.set_url('http://www.ruby-lang.org/robots.txt')
>>> rp.read()
>>> rp.can_fetch('*', 'http://www.ruby-lang.org/')
1
>>> rp.can_fetch('*', 'http://www.ruby-lang.org/doc/')
0
>>> rp.set_url('http://www.example.com/robots.txt')
>>> rp.read()
>>> rp.can_fetch('*', 'http://www.example.com/')
True


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014237&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 15:27:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 15:27:09 2004
Subject: [Patches] [ python-Patches-997284 ] Allow pydoc to work with XP
	Themes (.manifest file)
Message-ID: 

Patches item #997284, was opened at 2004-07-24 14:52
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow pydoc to work with XP Themes (.manifest file)

Initial Comment:
In Python 2.3.4, if you run pydoc -g under Windows XP
when one of the special XP theme manifest files has
been defined for python.exe or pythonw.exe, pydoc will
cause an access violation when it closes.  One solution
is obviously to get rid of the manifest files, but
wxPython installs them by default and apps written with
it work without a problem.  So it would be nice if
pydoc would also work, and it turns out it didn't take
a big change.  Attached is a patch which fixes the
problem (at least on my system).  I noticed that idle
did not have the access violation problem, and so
copied what it does in PyShell.main.

It might be better to introduce a more general fix for
Tkinter.  The problem seems to be that Uxtheme.dll
frees up some global data before all the windows have
called CloseThemeData (at app shutdown).  The AV seems
to happen when a call to CloseThemeData (presumably in
response to a WM_DESTROY message) passes a bad pointer
to RtlEnterCriticalSection.  Anyway, it seems that if
you get the window handles destroyed earlier in
shutdown, the problem is fixed.  Perhaps there is some
way to provide the Tkinter module with an atexit
handler which would destroy any existing widgets?


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2004-08-23 05:27

Message:
Logged In: YES 
user_id=86307

I admit the cause is obscure, but I think the problem will
potentially affect most Tkinter programs (see for example,
www.python.org/sf/774188 -- which links to a wiki article
referring to crashes in Tkinter with manifest files
present).  I just tried pynche.pyw, redemo.py, wcgui.py, and
wsgui.py (from the Tools branch) and they all crashed on
exit (at the same location in kernel32, with the same
attempt to read 0x00000028).  This is with Python 2.3.4
under XP (I don't have access to an XP SP2 machine right
now: I wonder if this has been fixed).

Anyway, I added the following to Tkinter, and the crashes
went away (I don't usually use Tkinter, so this may not be
the best way to accomplish this):

import atexit

def _tkAtExit():
    if _default_root is not None:
        _default_root.destroy()

atexit.register(_tkAtExit)


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 08:15

Message:
Logged In: YES 
user_id=21627

This is quite an obscure problem, so I added a comment an
committed it as pydoc.py 1.86.8.3 and 1.97, NEWS 1.831.4.144.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470
From paulagrassi203 at hotmail.com  Mon Aug 23 18:15:28 2004
From: paulagrassi203 at hotmail.com (Paula O. Grassi)
Date: Mon Aug 23 18:15:31 2004
Subject: [Patches] =?iso-8859-1?q?email=2C_mala_direta=2C_propaganda_e-ma?=
	=?iso-8859-1?q?il=2C_marketing_por_e-mails_listas_de_divulga=E7=E3?=
	=?iso-8859-1?q?o?=
Message-ID: <20040823161529.F0BA71E4014@bag.python.org>

Visite agora:   http://www.divulgamail.mx.gs

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 

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

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

emails 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-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  Mon Aug 23 22:03:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 22:03:51 2004
Subject: [Patches] [ python-Patches-997284 ] Allow pydoc to work with XP
	Themes (.manifest file)
Message-ID: 

Patches item #997284, was opened at 2004-07-25 00:52
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow pydoc to work with XP Themes (.manifest file)

Initial Comment:
In Python 2.3.4, if you run pydoc -g under Windows XP
when one of the special XP theme manifest files has
been defined for python.exe or pythonw.exe, pydoc will
cause an access violation when it closes.  One solution
is obviously to get rid of the manifest files, but
wxPython installs them by default and apps written with
it work without a problem.  So it would be nice if
pydoc would also work, and it turns out it didn't take
a big change.  Attached is a patch which fixes the
problem (at least on my system).  I noticed that idle
did not have the access violation problem, and so
copied what it does in PyShell.main.

It might be better to introduce a more general fix for
Tkinter.  The problem seems to be that Uxtheme.dll
frees up some global data before all the windows have
called CloseThemeData (at app shutdown).  The AV seems
to happen when a call to CloseThemeData (presumably in
response to a WM_DESTROY message) passes a bad pointer
to RtlEnterCriticalSection.  Anyway, it seems that if
you get the window handles destroyed earlier in
shutdown, the problem is fixed.  Perhaps there is some
way to provide the Tkinter module with an atexit
handler which would destroy any existing widgets?


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-23 22:03

Message:
Logged In: YES 
user_id=21627

I'd still woud prefer if a "proper" patch would be found,
i.e. one that doesn't cause a crash in response to
WM_DESTROY. For that, one would have to understand why it
crashes, and see whether it is Tk's fault - if so, Tk should
be fixed. If it really is presumed to be a Windows
bug/limitation, I'd like to see the KB article that
acknowledges the problem, and apply the work-around
suggested in the KB.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2004-08-23 15:27

Message:
Logged In: YES 
user_id=86307

I admit the cause is obscure, but I think the problem will
potentially affect most Tkinter programs (see for example,
www.python.org/sf/774188 -- which links to a wiki article
referring to crashes in Tkinter with manifest files
present).  I just tried pynche.pyw, redemo.py, wcgui.py, and
wsgui.py (from the Tools branch) and they all crashed on
exit (at the same location in kernel32, with the same
attempt to read 0x00000028).  This is with Python 2.3.4
under XP (I don't have access to an XP SP2 machine right
now: I wonder if this has been fixed).

Anyway, I added the following to Tkinter, and the crashes
went away (I don't usually use Tkinter, so this may not be
the best way to accomplish this):

import atexit

def _tkAtExit():
    if _default_root is not None:
        _default_root.destroy()

atexit.register(_tkAtExit)


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:15

Message:
Logged In: YES 
user_id=21627

This is quite an obscure problem, so I added a comment an
committed it as pydoc.py 1.86.8.3 and 1.97, NEWS 1.831.4.144.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 22:14:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 22:14:09 2004
Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...)
Message-ID: 

Patches item #764217, was opened at 2003-07-01 14:14
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L?wis (loewis)
Summary: Fix for tkFont.Font(name=...)

Initial Comment:
tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font.

This simple fix handles the problem.

I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-08-23 13:14

Message:
Logged In: YES 
user_id=431773

Thank you very much for submitting this patch.

At risk of submarining this useful patch, I fear the __del__ 
change may be important.

The main point of the patch is so that Tkinter users can deal with 
a tk named font when all they have is the name. So...what can go 
wrong with deleting the tk named font when a tkFont object goes 
away?

Consider the following sequence:
- subroutine A creates a tkFont, which creates a new tk named 
font
- subroutine B knows the name of the font, but does not have the 
original tkFont object. So it creates a copy using name=...
- subroutine A finishes with the tkFont object and so it is garbage-
collected
- subroutine B's tkFont object mysteriously stops working because 
the underlying tk named font has been destroyed.

I found this sequence occurring in my own test code and it is the 
reason I deleted the __del__ object.

Other arguments for not deleting tk named fonts when tkFont 
objects go away:
- It is important if one has used named fonts to configure widgets 
(and this is the primary reason I know of for creating named 
fonts).
- It matches tk's own behavior.

I don't believe leaving tk fonts around has any significant down 
sides. One can certainly imagine memory use issues, but a user 
would have to create an unreasonable # of fonts to notice 
anything.

An alternative that requires more code is to use a dictionary to 
maintain a reference count by font name. When the count goes 
to zero, delete the tk named font. But yecch...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 04:07

Message:
Logged In: YES 
user_id=21627

I have committed this change as tkFont.py 1.6, NEWS 1.1099.
I have left __del__; the font is now deleted in __del__ if
it was created in __init__.


----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-06-01 10:28

Message:
Logged In: YES 
user_id=431773

Just a tickle, hoping this can get into Python 2.4

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-12-11 15:22

Message:
Logged In: YES 
user_id=431773

Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit".

There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming.

I see two solutions:
- Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue.
- Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 10:05

Message:
Logged In: YES 
user_id=431773

Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable).

The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step.

Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 09:43

Message:
Logged In: YES 
user_id=431773

I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used).

 I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress).

Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts.

Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 04:01

Message:
Logged In: YES 
user_id=21627

reowen, are you willing to revise the patch in this direction?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-13 08:57

Message:
Logged In: YES 
user_id=21627

While the bug might be worth fixing, I think the approach
taken is wrong. With the patch, it will invoke "font names"
for all new tkFont objects, which might be a significant
overhead.

To really preserve current behaviour, it should continue to
'font create', and fall back to 'font configure' in case of
an exception.

Actually, it is not clear what the right behaviour is in the
first place. 'font configure' would change the settings of
the existing font. If the name clash is by coincidence, it
would be better to raise an exception instead of silently
modifying the existing font.

In the face of ambiguity, refuse the temptation to guess.

So to really fix this, tkFont.forName (or tkFont.existing)
should be provided.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-13 08:32

Message:
Logged In: YES 
user_id=80475

The first part of the patch appears reasonable.  For the 
second part, it's a bit late for an API change.

Martin, is this bugfix okay for Py2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 22:27:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 22:27:05 2004
Subject: [Patches] [ python-Patches-562100 ] Installation database patch
Message-ID: 

Patches item #562100, was opened at 2002-05-29 17:21
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Installation database patch

Initial Comment:
The attached patch implements an installation database.

This patch is not yet correct; don't bother proofreading it 
yet.  I simply wanted to create a patch number so I could 
put it in PEP 262.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-08-23 16:27

Message:
Logged In: YES 
user_id=11375

No one is championing it any longer; closing the patch.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 12:44

Message:
Logged In: YES 
user_id=21627

What is the status of this patch? I see that the PEP still
has open issues. Who is championing this technology?

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-08 14:50

Message:
Logged In: YES 
user_id=3066

Just a note:  The install_db.py file is in Python's CVS, in
nondist/sandbox/pep262/.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-02-24 18:02

Message:
Logged In: YES 
user_id=3066

The attached patch implies the addition of the file
install_db.py, but does not include that file.  Please
attach that file to this patch report as well.

Thanks!

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-01-30 12:29

Message:
Logged In: YES 
user_id=11375

Reviving this patch.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-10-03 16:19

Message:
Logged In: YES 
user_id=139309

This should be brought back into play (patch finished, PEP heavily 
considered, or however that goes), the Package Manager effort 
going on in pythonmac-sig needs this functionality as part of 
distutils.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-10-24 15:13

Message:
Logged In: YES 
user_id=11375

Closing this patch with the withdrawal of PEP 262.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 22:34:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 22:34:33 2004
Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...)
Message-ID: 

Patches item #764217, was opened at 2003-07-01 23:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L?wis (loewis)
Summary: Fix for tkFont.Font(name=...)

Initial Comment:
tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font.

This simple fix handles the problem.

I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-23 22:34

Message:
Logged In: YES 
user_id=21627

Can you come up with a Python script that demonstrates the
problem with the deleted font, under the current CVS?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-08-23 22:14

Message:
Logged In: YES 
user_id=431773

Thank you very much for submitting this patch.

At risk of submarining this useful patch, I fear the __del__ 
change may be important.

The main point of the patch is so that Tkinter users can deal with 
a tk named font when all they have is the name. So...what can go 
wrong with deleting the tk named font when a tkFont object goes 
away?

Consider the following sequence:
- subroutine A creates a tkFont, which creates a new tk named 
font
- subroutine B knows the name of the font, but does not have the 
original tkFont object. So it creates a copy using name=...
- subroutine A finishes with the tkFont object and so it is garbage-
collected
- subroutine B's tkFont object mysteriously stops working because 
the underlying tk named font has been destroyed.

I found this sequence occurring in my own test code and it is the 
reason I deleted the __del__ object.

Other arguments for not deleting tk named fonts when tkFont 
objects go away:
- It is important if one has used named fonts to configure widgets 
(and this is the primary reason I know of for creating named 
fonts).
- It matches tk's own behavior.

I don't believe leaving tk fonts around has any significant down 
sides. One can certainly imagine memory use issues, but a user 
would have to create an unreasonable # of fonts to notice 
anything.

An alternative that requires more code is to use a dictionary to 
maintain a reference count by font name. When the count goes 
to zero, delete the tk named font. But yecch...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 13:07

Message:
Logged In: YES 
user_id=21627

I have committed this change as tkFont.py 1.6, NEWS 1.1099.
I have left __del__; the font is now deleted in __del__ if
it was created in __init__.


----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-06-01 19:28

Message:
Logged In: YES 
user_id=431773

Just a tickle, hoping this can get into Python 2.4

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-12-12 00:22

Message:
Logged In: YES 
user_id=431773

Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit".

There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming.

I see two solutions:
- Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue.
- Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 19:05

Message:
Logged In: YES 
user_id=431773

Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable).

The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step.

Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 18:43

Message:
Logged In: YES 
user_id=431773

I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used).

 I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress).

Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts.

Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 13:01

Message:
Logged In: YES 
user_id=21627

reowen, are you willing to revise the patch in this direction?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-13 17:57

Message:
Logged In: YES 
user_id=21627

While the bug might be worth fixing, I think the approach
taken is wrong. With the patch, it will invoke "font names"
for all new tkFont objects, which might be a significant
overhead.

To really preserve current behaviour, it should continue to
'font create', and fall back to 'font configure' in case of
an exception.

Actually, it is not clear what the right behaviour is in the
first place. 'font configure' would change the settings of
the existing font. If the name clash is by coincidence, it
would be better to raise an exception instead of silently
modifying the existing font.

In the face of ambiguity, refuse the temptation to guess.

So to really fix this, tkFont.forName (or tkFont.existing)
should be provided.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-13 17:32

Message:
Logged In: YES 
user_id=80475

The first part of the patch appears reasonable.  For the 
second part, it's a bit late for an API change.

Martin, is this bugfix okay for Py2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 22:44:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 22:44:17 2004
Subject: [Patches] [ python-Patches-1014237 ] RobotFileParser.can_fetch
	return value
Message-ID: 

Patches item #1014237, was opened at 2004-08-23 12:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014237&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: RobotFileParser.can_fetch return value

Initial Comment:
Currently, RobotFileParser.can_fetch method returns two 
kinds of types(int and bool) and is not consistent.

More strictly, if a web site sets a robots.txt file, it 
returns 1/0. Otherwise, it returns boolean(True/False).

My change is to make can_fetch method return bool 
values in either case as documented in robotparser 
module.

# examples of can_fetch return values
>>> import robotparser
>>> rp = robotparser.RobotFileParser()
>>> rp.set_url('http://www.ruby-lang.org/robots.txt')
>>> rp.read()
>>> rp.can_fetch('*', 'http://www.ruby-lang.org/')
1
>>> rp.can_fetch('*', 'http://www.ruby-lang.org/doc/')
0
>>> rp.set_url('http://www.example.com/robots.txt')
>>> rp.read()
>>> rp.can_fetch('*', 'http://www.example.com/')
True


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-23 22:44

Message:
Logged In: YES 
user_id=21627

Thanks for the patch.  Committed as robotparser.py 1.20. As
this patch is a slight interface change, I think it is not
appropriate for 2.3: 2.3 applications should be easily
enough capable of working around this problem, and the
change may actually break applications who really care about
the type of the return value.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014237&group_id=5470
From noreply at sourceforge.net  Mon Aug 23 23:41:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 23 23:41:11 2004
Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...)
Message-ID: 

Patches item #764217, was opened at 2003-07-01 14:14
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. L?wis (loewis)
Summary: Fix for tkFont.Font(name=...)

Initial Comment:
tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font.

This simple fix handles the problem.

I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-08-23 14:41

Message:
Logged In: YES 
user_id=431773

The sample script shows the basic issue. The setFontSize call 
should not have to know or care if the original tkFont object was 
destroyed or not. Unfortunately, with __del__ it dies if the original 
tkFont object is destroyed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-23 13:34

Message:
Logged In: YES 
user_id=21627

Can you come up with a Python script that demonstrates the
problem with the deleted font, under the current CVS?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-08-23 13:14

Message:
Logged In: YES 
user_id=431773

Thank you very much for submitting this patch.

At risk of submarining this useful patch, I fear the __del__ 
change may be important.

The main point of the patch is so that Tkinter users can deal with 
a tk named font when all they have is the name. So...what can go 
wrong with deleting the tk named font when a tkFont object goes 
away?

Consider the following sequence:
- subroutine A creates a tkFont, which creates a new tk named 
font
- subroutine B knows the name of the font, but does not have the 
original tkFont object. So it creates a copy using name=...
- subroutine A finishes with the tkFont object and so it is garbage-
collected
- subroutine B's tkFont object mysteriously stops working because 
the underlying tk named font has been destroyed.

I found this sequence occurring in my own test code and it is the 
reason I deleted the __del__ object.

Other arguments for not deleting tk named fonts when tkFont 
objects go away:
- It is important if one has used named fonts to configure widgets 
(and this is the primary reason I know of for creating named 
fonts).
- It matches tk's own behavior.

I don't believe leaving tk fonts around has any significant down 
sides. One can certainly imagine memory use issues, but a user 
would have to create an unreasonable # of fonts to notice 
anything.

An alternative that requires more code is to use a dictionary to 
maintain a reference count by font name. When the count goes 
to zero, delete the tk named font. But yecch...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-18 04:07

Message:
Logged In: YES 
user_id=21627

I have committed this change as tkFont.py 1.6, NEWS 1.1099.
I have left __del__; the font is now deleted in __del__ if
it was created in __init__.


----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-06-01 10:28

Message:
Logged In: YES 
user_id=431773

Just a tickle, hoping this can get into Python 2.4

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-12-11 15:22

Message:
Logged In: YES 
user_id=431773

Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit".

There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming.

I see two solutions:
- Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue.
- Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 10:05

Message:
Logged In: YES 
user_id=431773

Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable).

The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step.

Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 09:43

Message:
Logged In: YES 
user_id=431773

I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used).

 I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress).

Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts.

Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-09-20 04:01

Message:
Logged In: YES 
user_id=21627

reowen, are you willing to revise the patch in this direction?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-13 08:57

Message:
Logged In: YES 
user_id=21627

While the bug might be worth fixing, I think the approach
taken is wrong. With the patch, it will invoke "font names"
for all new tkFont objects, which might be a significant
overhead.

To really preserve current behaviour, it should continue to
'font create', and fall back to 'font configure' in case of
an exception.

Actually, it is not clear what the right behaviour is in the
first place. 'font configure' would change the settings of
the existing font. If the name clash is by coincidence, it
would be better to raise an exception instead of silently
modifying the existing font.

In the face of ambiguity, refuse the temptation to guess.

So to really fix this, tkFont.forName (or tkFont.existing)
should be provided.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-13 08:32

Message:
Logged In: YES 
user_id=80475

The first part of the patch appears reasonable.  For the 
second part, it's a bit late for an API change.

Martin, is this bugfix okay for Py2.3?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 01:26:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 01:27:01 2004
Subject: [Patches] [ python-Patches-1007087 ] Return new string for single
	subclass joins (Bug #1001011)
Message-ID: 

Patches item #1007087, was opened at 2004-08-11 03:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Return new string for single subclass joins (Bug #1001011)

Initial Comment:
At present, str.join contains a shortcut that returns a
reference to the existing string for a sequence that
contains a single item.

This can cause misbehaviour when subclasses of str are
involved (see the bug report for details).

The attached patch removes the shortcut, and adds a
test for the correct behaviour.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-23 18:26

Message:
Logged In: YES 
user_id=80475

Applied as:
   Objects/stringobject.c 2.225
   Lib/test/test_string.py 1.26

Thanks for the perfect patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-19 17:28

Message:
Logged In: YES 
user_id=31435

Unassigned myself -- can't make time for this now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-19 17:17

Message:
Logged In: YES 
user_id=80475

The patch looks good, it compiles okay, and the test_suite
passes.

If Tim has no further issues, I will apply it.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 17:53

Message:
Logged In: YES 
user_id=1038590

Oh - the test looks explicitly for the optimised behaviour
for a true string (to make sure this version preserved that
behaviour). Is that a good idea, or not?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 17:52

Message:
Logged In: YES 
user_id=1038590

New version of patch attached which uses PyString_CheckExact
and PyUnicode_CheckExact to determine when the optimisation
is safe, and falls through to the general case when it isn't.

Should this optimisation be applied to the unicode join as well?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-11 17:17

Message:
Logged In: YES 
user_id=1038590

OK. I think I can do something with PyString_CheckExact that
will do what you'd prefer.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-11 07:52

Message:
Logged In: YES 
user_id=31435

This is an important optimization for "true strings".  It was 
indeed the intent that internal optimization for immutable 
types not be applied to subclass instances, so it's good to fix 
that.  It's not good to lose the optimization when it's safe.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007087&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 01:38:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 01:39:04 2004
Subject: [Patches] [ python-Patches-1013667 ] Cleanup Peepholer Output
Message-ID: 

Patches item #1013667, was opened at 2004-08-22 00:34
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 6
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cleanup Peepholer Output

Initial Comment:
Makes the peepholer output more compact, more readable,
and a bit faster.  Also saves a bit of space in pyc files.

* Uses NOPs instead of JMP+3 or JMP+2.
* Then, makes a pass to eliminate the NOPs (which
entails re-aligning the jump targets and linenotab).
* Add a transform to get rid of the unnecessary Return
Nones followed by another Return in the same block.
* Fixed the overflow test (codelen < 65000) to coerce
codelen to unsigned before the check.

Michael, I would appreciate it if you could give this a
second look just to make sure before I check it in.  I
would like it to go in well before the next alpha.  The
patch passes the test suite, runs all my own apps, and
has run on my machine for about a week with any issues.
If you don't have time to give it a once over, please
assign to Armin.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-23 18:38

Message:
Logged In: YES 
user_id=80475

No reviewers responded to my emails.  Applying now so that
it gets exercised as much as possible before the next alpha
release.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-22 17:18

Message:
Logged In: YES 
user_id=80475

Added a revision with better formatting and more tests.

This patch is open for whoever has time to look at it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 04:44:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 04:44:38 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02: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=1014930&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 04:47:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 04:47:47 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02:44
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-24 02:47

Message:
Logged In: YES 
user_id=28658

Oops - obviously CurrentColumnNumber wraps
XML_GetCurrentColumnNumber, and CurrentLineNumber wraps
XML_GetCurrentLineNumber.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 06:48:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 06:48:28 2004
Subject: [Patches] [ python-Patches-1014992 ] bug in
	tarfile.ExFileObject.readline
Message-ID: 

Patches item #1014992, was opened at 2004-08-24 14:48
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=1014992&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in tarfile.ExFileObject.readline

Initial Comment:
TarFile objects produce file-like objects to represent
internal files in the archive. There appears to be a
bug in the readline implementation for these objects.

When you specify the size parameter for readline, the
standard function will try to read one line with at
most size characters. However, in the tarfile module,
it may return extra data beyond the end of the line
(and also not clean out the trailing \r).

The problem is that after reading the maximum data, we
break out of the loop before checking for a newline.
This is fixed by modifying the while test.

This patch may break existing code which uses this
'feature'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014992&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 07:53:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 07:53:27 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 11:25
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: Accepted
>Priority: 7
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 05:53

Message:
Logged In: YES 
user_id=908995

Is this patch waiting on anything else? Should I send out emails 
soliciting reviews from Fred and Jeremey?

Bumped priority since this should go in to the next alpha.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-14 10:14

Message:
Logged In: YES 
user_id=908995

Uploaded new patch. Changes:

  - Support trailing comma in from list (suggested by Michael
    Chermside on python-dev). This form is now acceptable:

      from os import (path,)

    but this is not:

      from os import path,

    I originally wanted to support the latter for consistency, but I
    don't think it's necessary (who would want to do that but not use
    parens?) and it's potentially confusing in a case like this:

      from sys import stdin,
      stdout

    which looks like it was intended to be one statement, but the
    second line is actually separate. The way the grammar is written,
    the case with a trailing comma but no parentheses parses okay, but
    it is intentionally rejected by the compiler.

  - Added more success and fail cases, incl. the "import (*)" case.

  - Added NEWS entry. (I'm uncertain whether providing this as part of
    a larger change actually helps; the file changes often enough that
    the patch stands a good chance of not applying cleanly.)

There should definitely be more docs, but I intentionally didn't try
to include unnecessary changes in this patch. As already mentioned,
that can be done later.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-13 14:56

Message:
Logged In: YES 
user_id=6380

+1 from a quick glance.

Missing a Misc/NEWS file update.

Suggestion: add "from sys import (*)" to the fail tests.

Please ask Fred to review the parser module changes.

Please ask Jeremy to review the compiler module changes.

Shouldn't there be more docs? Tutorial examples? Etc.

All that can be done after it's checked in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 07:57:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 07:57:18 2004
Subject: [Patches] [ python-Patches-1015012 ] Improve markup and punctuation
	in libsocket.tex
Message-ID: 

Patches item #1015012, was opened at 2004-08-24 05:57
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=1015012&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve markup and punctuation in libsocket.tex

Initial Comment:
- Use \constant around AF_* constants
- Avoid comma splice

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 08:06:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 08:06:57 2004
Subject: [Patches] [ python-Patches-1015012 ] Improve markup and punctuation
	in libsocket.tex
Message-ID: 

Patches item #1015012, was opened at 2004-08-24 05:57
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve markup and punctuation in libsocket.tex

Initial Comment:
- Use \constant around AF_* constants
- Avoid comma splice

----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:06

Message:
Logged In: YES 
user_id=908995

Might as well fix the docstring as well while I'm picking nits. Uploaded 
new patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 08:07:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 08:07:47 2004
Subject: [Patches] [ python-Patches-1015012 ] Improve markup and punctuation
	in libsocket.tex
Message-ID: 

Patches item #1015012, was opened at 2004-08-24 05:57
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
>Assigned to: Dave Cole (davecole)
Summary: Improve markup and punctuation in libsocket.tex

Initial Comment:
- Use \constant around AF_* constants
- Avoid comma splice

----------------------------------------------------------------------

>Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:07

Message:
Logged In: YES 
user_id=908995

Assigned to davecole since he added socketpair

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:06

Message:
Logged In: YES 
user_id=908995

Might as well fix the docstring as well while I'm picking nits. Uploaded 
new patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 08:24:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 08:24:52 2004
Subject: [Patches] [ python-Patches-1015021 ] Docs claim that coerce can
	return None
Message-ID: 

Patches item #1015021, was opened at 2004-08-24 06:24
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=1015021&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docs claim that coerce can return None

Initial Comment:
The coerce builtin can't return None, but its docstring says
otherwise. As far back as I bothered to look (rev 2.98 of
bltnmodule.c in 1997), the implementation hasn't been able
to return None, so it's the docs that should be fixed.

Attached patch fixes the docstring and improves the library
reference to document what really happens if coercion fails.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015021&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 08:45:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 08:45:52 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02:44
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:45

Message:
Logged In: YES 
user_id=908995

The patch looks good to me after a quick glance and test
run. Maybe add something to the test suite to exercise these
attributes? It should be as easy as adding print statements
to a handler or two (the test relies heavily on comparing
the output to a known one). Most of the other attributes
aren't tested-for by the test suite, though. \versionadded
in the docs might be nice, too--just once, after the
paragraph introducing them.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-24 02:47

Message:
Logged In: YES 
user_id=28658

Oops - obviously CurrentColumnNumber wraps
XML_GetCurrentColumnNumber, and CurrentLineNumber wraps
XML_GetCurrentLineNumber.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 11:53:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 11:53:25 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 21:25
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-24 19:53

Message:
Logged In: YES 
user_id=29957

I'll be checking this in shortly.

(aside: please don't monkey with the priority settings...
thanks)


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 15:53

Message:
Logged In: YES 
user_id=908995

Is this patch waiting on anything else? Should I send out emails 
soliciting reviews from Fred and Jeremey?

Bumped priority since this should go in to the next alpha.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-14 20:14

Message:
Logged In: YES 
user_id=908995

Uploaded new patch. Changes:

  - Support trailing comma in from list (suggested by Michael
    Chermside on python-dev). This form is now acceptable:

      from os import (path,)

    but this is not:

      from os import path,

    I originally wanted to support the latter for consistency, but I
    don't think it's necessary (who would want to do that but not use
    parens?) and it's potentially confusing in a case like this:

      from sys import stdin,
      stdout

    which looks like it was intended to be one statement, but the
    second line is actually separate. The way the grammar is written,
    the case with a trailing comma but no parentheses parses okay, but
    it is intentionally rejected by the compiler.

  - Added more success and fail cases, incl. the "import (*)" case.

  - Added NEWS entry. (I'm uncertain whether providing this as part of
    a larger change actually helps; the file changes often enough that
    the patch stands a good chance of not applying cleanly.)

There should definitely be more docs, but I intentionally didn't try
to include unnecessary changes in this patch. As already mentioned,
that can be done later.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-14 00:56

Message:
Logged In: YES 
user_id=6380

+1 from a quick glance.

Missing a Misc/NEWS file update.

Suggestion: add "from sys import (*)" to the fail tests.

Please ask Fred to review the parser module changes.

Please ask Jeremy to review the compiler module changes.

Shouldn't there be more docs? Tutorial examples? Etc.

All that can be done after it's checked in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 12:15:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 12:15:55 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 lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
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: 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 Aug 24 13:12:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 13:12:23 2004
Subject: [Patches] [ python-Patches-1013667 ] Cleanup Peepholer Output
Message-ID: 

Patches item #1013667, was opened at 2004-08-22 06:34
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Closed
Resolution: None
Priority: 6
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cleanup Peepholer Output

Initial Comment:
Makes the peepholer output more compact, more readable,
and a bit faster.  Also saves a bit of space in pyc files.

* Uses NOPs instead of JMP+3 or JMP+2.
* Then, makes a pass to eliminate the NOPs (which
entails re-aligning the jump targets and linenotab).
* Add a transform to get rid of the unnecessary Return
Nones followed by another Return in the same block.
* Fixed the overflow test (codelen < 65000) to coerce
codelen to unsigned before the check.

Michael, I would appreciate it if you could give this a
second look just to make sure before I check it in.  I
would like it to go in well before the next alpha.  The
patch passes the test suite, runs all my own apps, and
has run on my machine for about a week with any issues.
If you don't have time to give it a once over, please
assign to Armin.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-08-24 12:12

Message:
Logged In: YES 
user_id=6656

Raymond, for the future: it's pretty rare for me to read my
email at the weekend...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-24 00:38

Message:
Logged In: YES 
user_id=80475

No reviewers responded to my emails.  Applying now so that
it gets exercised as much as possible before the next alpha
release.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-22 23:18

Message:
Logged In: YES 
user_id=80475

Added a revision with better formatting and more tests.

This patch is open for whoever has time to look at it first.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013667&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 14:21:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 14:21:07 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 21:25
Message generated for change (Settings changed) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: Accepted
>Priority: 9
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-24 19:53

Message:
Logged In: YES 
user_id=29957

I'll be checking this in shortly.

(aside: please don't monkey with the priority settings...
thanks)


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 15:53

Message:
Logged In: YES 
user_id=908995

Is this patch waiting on anything else? Should I send out emails 
soliciting reviews from Fred and Jeremey?

Bumped priority since this should go in to the next alpha.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-14 20:14

Message:
Logged In: YES 
user_id=908995

Uploaded new patch. Changes:

  - Support trailing comma in from list (suggested by Michael
    Chermside on python-dev). This form is now acceptable:

      from os import (path,)

    but this is not:

      from os import path,

    I originally wanted to support the latter for consistency, but I
    don't think it's necessary (who would want to do that but not use
    parens?) and it's potentially confusing in a case like this:

      from sys import stdin,
      stdout

    which looks like it was intended to be one statement, but the
    second line is actually separate. The way the grammar is written,
    the case with a trailing comma but no parentheses parses okay, but
    it is intentionally rejected by the compiler.

  - Added more success and fail cases, incl. the "import (*)" case.

  - Added NEWS entry. (I'm uncertain whether providing this as part of
    a larger change actually helps; the file changes often enough that
    the patch stands a good chance of not applying cleanly.)

There should definitely be more docs, but I intentionally didn't try
to include unnecessary changes in this patch. As already mentioned,
that can be done later.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-14 00:56

Message:
Logged In: YES 
user_id=6380

+1 from a quick glance.

Missing a Misc/NEWS file update.

Suggestion: add "from sys import (*)" to the fail tests.

Please ask Fred to review the parser module changes.

Please ask Jeremy to review the compiler module changes.

Shouldn't there be more docs? Tutorial examples? Etc.

All that can be done after it's checked in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Tue Aug 24 15:14:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 16:02:25 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 anthonybaxter
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: Open
Resolution: None
>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: 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  Tue Aug 24 18:59:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 18:59:34 2004
Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2)
Message-ID: 

Patches item #736962, was opened at 2003-05-13 05:45
Message generated for change (Comment added) made by rhettinger
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: Raymond Hettinger (rhettinger)
Date: 2004-08-24 11: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 11: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 10: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 10: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 14: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 08: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 11: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 18:02

Message:
Logged In: YES 
user_id=80475

Looks good.


----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-05-28 15: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 14: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 15: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 15: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 14: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 11: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 06: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 07: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 15:26

Message:
Logged In: YES 
user_id=80475

Okay, this one is fine.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2003-12-18 18: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 17: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 16: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 15: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 07: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 01: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 00: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 06: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 18:49

Message:
Logged In: YES 
user_id=80475

Looks good.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2003-11-27 14: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 20: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 18: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 14: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 18: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 12:10

Message:
Logged In: YES 
user_id=80475

Will do!

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2003-08-30 12: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 10: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 08: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 06: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 14: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 04: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 14: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 09: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 18: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 16: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 07: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 16: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 14: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 14: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 14: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 14: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 13: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 13: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 11: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 10: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 10: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 07: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 12: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 11:18

Message:
Logged In: YES 
user_id=80475

test_mimetools.py is ready.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2003-05-22 10: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 08: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 18: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 22: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 21: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 20: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 20: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 20: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 19: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 18: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 Aug 24 22:02:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 22:02:38 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: Open
Resolution: None
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-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 Aug 24 23:50:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 24 23:51:01 2004
Subject: [Patches] [ python-Patches-945642 ] nonblocking i/o with ssl socket
	not working at all
Message-ID: 

Patches item #945642, was opened at 2004-05-01 00:14
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Tino Lange (tinolange)
Assigned to: A.M. Kuchling (akuchling)
Summary: nonblocking i/o with ssl socket not working at all

Initial Comment:
Hi!

Unfortunately the applied patches #675750 and #676472
(End of January by G. Talvola / B. Laurie / G. v.
Rossum) for timeout-sockets in version 1.09 and 1.10 to
Modules/_ssl.c broke the nonblocking SSL I/O.

In fact sslobj.read() became *always* blocking -
whether the underlying socket is blocking or
nonblocking doesn't matter at all.

In Python < 2.3 this has worked correctly, starting
with 2.3, 2.3.x up to the current CVS it doesn't work
anymore.

Attached is a sample:

0) [ Preparation ]
Please run stunnel on your machine to have a SSL service:
/usr/sbin/stunnel -p /path/to/some/cert -f -d 4711 -r 4712

1) [ Server ]
Please run the easy server.py 

2) [Client showing the bug]
Please run the client - and see how it hangs when you
use Python2.3.

Also attached is a diff against the current _ssl.c
which shows how to correct that behaviour while also
having the possibilities from the above timeout patches.

I carefully tested it,  please review and test yourself
and finally check-in.

If you have questions, please don't hesitate to ask me.

I really would like to see that not only in 2.4, but
also (if possible together with patch #909007 from S.
Nicolary) in a 2.3.4 release. Otherwise 2.3.x wasn't at
all able to handle nonblocking SSL connections properly.

Thanks and cheers,

Tino

----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2004-08-24 23:50

Message:
Logged In: YES 
user_id=60903

Applied to the 2.3 branch in Modules/_ssl.c: 1.13.6.4


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 23:23

Message:
Logged In: YES 
user_id=11375

Committed to CVS head; thanks for all your work!

----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-07-10 22:05

Message:
Logged In: YES 
user_id=212920

BTW:
>From reading the Bug Summary I think that applying this
patch will also fix Bug #977680.

Please test afterwards.

----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-07-10 21:59

Message:
Logged In: YES 
user_id=212920

Hi!

Did you really start stunnel? It fakes the server.py LISTEN
on 4712 as ssl service listening on 4711.

I have stunnel 3.22 here. The options on 4.x might be
completely different.

You should see:

1) stunnel
tino@tinont:$ /usr/sbin/stunnel -p /path/to/some.cert  -f -d
4711 -r 4712
2004.07.10 21:49:56 LOG5[6518:1024]: Using '4712' as
tcpwrapper service name
2004.07.10 21:49:56 LOG5[6518:1024]: stunnel 3.22 on
i586-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.6c 21 dec
2001
2004.07.10 21:49:56 LOG5[6518:1024]: FD_SETSIZE=1024, file
ulimit=1024 -> 500 clients allowed

2) server.py

tino@tinont:$ python server.py
server is waiting for client connection on port 4712!

3) client.py

a) python 2.1

tino@tinont:$ python client.py

SSL Issuer: '...'
SSL Server: '...'

... selecting, readset = [3], timeout = 1.0
... returning from select - r = [3]
... something to read from socket/ssl has arrived!
... going to read from sslobj
... read 'Hallo
'
... going to read from sslobj

... (ignored) ## SSL Socket Error (11): 'Resource
temporarily unavailable' ##
Hallo
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = [3]
... something to read from socket/ssl has arrived!
... going to read from sslobj
... read
'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
'
... going to read from sslobj

... (ignored) ## SSL Socket Error (11): 'Resource
temporarily unavailable' ##
HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = [3]
... something to read from socket/ssl has arrived!
... going to read from sslobj
... read
'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall'
... going to read from sslobj
... read
'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal'
... going to read from sslobj
... read
'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa'
... going to read from sslobj
... read
'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH'
... going to read from sslobj
... read
'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
'
... going to read from sslobj

... (ignored) ## SSL Socket Error (11): 'Resource
temporarily unavailable' ##
HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = []
... selecting, readset = [3], timeout = 1.0
... returning from select - r = [3]
... something to read from socket/ssl has arrived!
... going to read from sslobj
... read ''

## SSL Socket: Counterpart has closed the connection ##
tino@tinont:$

b) python 2.3.x or 2.4

tino@tinont:$ python2.3 client.py

SSL Issuer: '...'
SSL Server: '...'

... selecting, readset = [3], timeout = 1.0
... returning from select - r = [3]
... something to read from socket/ssl has arrived!
... going to read from sslobj
... read 'Hallo
'
... going to read from sslobj
... read
'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
'
... going to read from sslobj
... read
'HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHall'
... going to read from sslobj
... read
'oHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHal'
... going to read from sslobj
... read
'loHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHa'
... going to read from sslobj
... read
'lloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloH'
... going to read from sslobj
... read
'alloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
'
... going to read from sslobj

... (ignored) ## SSL Socket Error (6): 'TLS/SSL connection
has been closed' ##
Hallo
HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo
HalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHalloHallo

## SSL Socket: Counterpart has closed the connection ##
tino@tinont:$


As you can see the client.py completely blocks while the
server is sleeping between sending some data when using
python 2.3.x or 2.4.

In 2.1 and 2.2 the client.py returns as expected for a
nonblocking client in between - and select tells us when we
can continue reading.

Hope this helps

Tino


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 21:12

Message:
Logged In: YES 
user_id=11375

The test programs don't work for me, either with or without the patch.  
They both crash with 'error:140770FC:SSL routines:
SSL23_GET_SERVER_HELLO:unknown protocol'.  What should I be seeing?


----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-05-12 00:20

Message:
Logged In: YES 
user_id=212920

OK. Fine :-)

Please find below in file
"patch_honoring_the_style_guide.diff" an slightly changed
version of my original patch that follows the PEP7 better
(for the single else statements containg only one commad
without parantheses) - but still honors the rest of the file
also.

Only the formatting has changed a little bit, no content.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-05-11 19:17

Message:
Logged In: YES 
user_id=357491

The way you showed it, Tino, is correct.  And I didn't realize the file was 
not following the spec.

At this point, though, since we are trying to get someone to check this in 
before 2.3.4 goes out the door I wouldn't worry about it too much.  Going 
in and fixing the syntax afterwards is not a huge deal.

So if you have the time, great.  Otherwise, because we have this 
possible time constraint and whom ever wrote the file in the first place 
didn't follow it, I wouldn't not worry about it too much.

----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-05-11 09:53

Message:
Logged In: YES 
user_id=212920

Thanks for the hint.

I guess --in the context of _ssl.c -- you only complain
about the lines:

 } else sockstate = SOCKET_OPERATION_OK;

or? Is that right?

I think all the other else's are consistent - at least with
the rest of the file - and some others I looked into (for
example _bsddb.c).

Or do you think that I shall reformat all the other else's
in the file? Also those that are not from me?

Really following the PEP it should look like:

if (foo) {
 ...
}
else if (otherfoo) {
 ...
}
else {
 ...
}

instead of 

if (foo) {
 ...
} else if (otherfoo) {
 ...
} else {
 ...
}

everywhere, or?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-05-11 03:10

Message:
Logged In: YES 
user_id=357491

A style nit: put 'else' statements on their own line.  See PEP 7 (http://
www.python.org/peps/pep-0007.html) on C code guidelines.

But I am no network programmer so I have no clue if the solution is 
good.

----------------------------------------------------------------------

Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks)
Date: 2004-05-03 20:14

Message:
Logged In: YES 
user_id=1033524

Hi Tino.

I'll take your word for it. I though your ssl was based on the 
included SocketServer.py

Cheers JJ

----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-05-02 10:40

Message:
Logged In: YES 
user_id=212920

Hi JJ,

I just scanned your SocketServer.py - and I really don't see
how this  class might help? You don't offer a better
sslob.read() there, don't you?

So how could it help (besides maybe making my example
"server.py nicer).

If I put a sslobj on top of a socket object it is blocking
in 2.3, 2.3.x and higher. As proven in my example: Making
the underlying socket nonblocking has no effect - because
SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE from the
SSL_xxx() functions in the C-Library do not break out of the
while loop that was introduced in the above mentioned patches.

Cheers,

Tino

----------------------------------------------------------------------

Comment By: Jesper ?JJ? Jurcenoks (jesperjurcenoks)
Date: 2004-05-02 04:46

Message:
Logged In: YES 
user_id=1033524

Hi Tino.

I just submitted a nonblocking SocketServer.py, it might just 
solve your problem.

JJ

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 00:24:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 00:24:56 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-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  Wed Aug 25 00:35:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 00:35:32 2004
Subject: [Patches] [ python-Patches-776854 ] expose lowlevel setlocale
Message-ID: 

Patches item #776854, was opened at 2003-07-24 20:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=776854&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: expose lowlevel setlocale

Initial Comment:
I propose (for post 2.3) we expose a lowlevel
setlocale() for diagnostic purposes.  Specifically, I
propose that release builds support only querying the
current locale, but Py_DEBUG builds be capable of
bypassing Python completely.

This is somewhat complementary to [ 774665 ] making
Python LC_NUMERIC agnostic

This would be extremely good for Windows - hence my
patch adds such a method to the "msvcrt" module. 
However, I believe it worthy of consideration for
locale itself, seeing as it is impossible to have
Python-related side effects in release builds.  For
people running debug builds (or capable of switching to
them) it provides invaluable help.

Assigning to Tim to pronounce on.  Either reject it,
accept for msvcrt (and I will check it in post 1.3) or
accept in principle for _locale, then assign back.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-08-25 08:34

Message:
Logged In: YES 
user_id=14198

Attached is a patch which names the new method
"locale._setlocale()"

An alternative and possibly better name would be
"getcrtlocale()" - any thoughts?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-25 04:24

Message:
Logged In: YES 
user_id=21627

I accept that in principle for _locale, unconditionally,
under a name different from "setlocale".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=776854&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 02:53:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 02:54:00 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-04 16:23
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2004-08-24 17:53

Message:
Logged In: YES 
user_id=971153

attaching the new patch

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-22 09:32

Message:
Logged In: YES 
user_id=971153

I am attaching a new version of the patch.

In addition to issues raised earlier the v1 version of patch
had a couple of other problems:

1. funcname based breakpoints got a wrong hit statistics
(hit counter was incremented on every effective() call,
which happened for every line of a function with a funcname
bkpt)

2. If a user set a bkpt via line number at def statement
(this is probably quite rare, but still possible) , then pdb
would stop at every line of that function when the function
is called

To fix these I had to move most of funcname handling logic
from break_here() into a separate function
(bdb.checkfuncname) and call it from bdb.effective()

Changes in the new version include: 

1. Fix the issues with statistics and bkpts at def stmt

2. Fix a doc line of checkline()

3. Rename .breakingline into .func_first_executable_line

4. Comment fixes


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-14 20:30

Message:
Logged In: YES 
user_id=971153

Ok, I'll submit an updated patch hopefully by the end of the
next week (I will be out of town for the next few days).

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 03:40

Message:
Logged In: YES 
user_id=469548

"Well, I am not sure: func_firstlineno causes a wrong
association with co_firstlineno (while these are almost
never the same)."

Ah, I misread the patch there. How about
func_first_executable_lineno (or something like that)? Or am
I off-base again?

"Would the following be better?"

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 
"

Yes. I was just having a bit of a hard time following your
patch. I think this is clearer.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-13 12:24

Message:
Logged In: YES 
user_id=971153


>- The checkline() docstring needs to be updated.
>- Try not to use multi-line comments after a statement
>(e.g.: 'return False #it's not a func call, but rather', etc.).

Ok, I can resubmit a patch for these two


>- For consistency, Breakpoint.breakingline should probably
>be called func_firstlineno.

Well, I am not sure: func_firstlineno causes a wrong
association with
co_firstlineno (while these are almost never the same).
Furthermore,
the  name ".breakingline" reflects the purpose: "a line
number where to break", while, "func_firstlineno" is totatly
neutral..
 

>- Moving the 'bp.breakingline=frame.f_lineno' statement into
>an else: branch of the 'if bp.breakingline and
>(bp.breakingline != frame.f_lineno)' statement would
>probably make the logic clearer.

Are you suggesting to replace:

                if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
                bp.breakingline=frame.f_lineno

with:

               if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
               else: 
                    bp.breakingline=frame.f_lineno

Why do you think it's better? It's definitely more verbose, has
an extra indentation level and looking through the code I
see a lot of code which looks like:

if  (....):
    return
foo
bar
without the else: branch


Would the following be better?

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 

Thus making it explicit that there are really 2 decisions
being made:
1) do we need to set the breakingline
2) do we need to break here


I don't have any strong feelings regarding these 2 issues,
just want to make sure that I understand the problem





----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 08:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 06:51:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 06:51:35 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-02 15:16
Message generated for change (Comment added) made by jeffconnelly
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: Open
Resolution: None
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: Jeff Connelly aka shellreef (jeffconnelly)
Date: 2004-08-24 21: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 03: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-02 15: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-02 15: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  Wed Aug 25 07:51:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 07:51:48 2004
Subject: [Patches] [ python-Patches-776854 ] expose lowlevel setlocale
Message-ID: 

Patches item #776854, was opened at 2003-07-24 12:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=776854&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: expose lowlevel setlocale

Initial Comment:
I propose (for post 2.3) we expose a lowlevel
setlocale() for diagnostic purposes.  Specifically, I
propose that release builds support only querying the
current locale, but Py_DEBUG builds be capable of
bypassing Python completely.

This is somewhat complementary to [ 774665 ] making
Python LC_NUMERIC agnostic

This would be extremely good for Windows - hence my
patch adds such a method to the "msvcrt" module. 
However, I believe it worthy of consideration for
locale itself, seeing as it is impossible to have
Python-related side effects in release builds.  For
people running debug builds (or capable of switching to
them) it provides invaluable help.

Assigning to Tim to pronounce on.  Either reject it,
accept for msvcrt (and I will check it in post 1.3) or
accept in principle for _locale, then assign back.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 07:51

Message:
Logged In: YES 
user_id=21627

AFAICT, the only change left between this function and
_locale.setlocale is that the latter also adjusts
string.upper etc. I wonder whether we should take this code
out of _localemodule.c, and move it into locale.py. In that
case, you could just use _locale.setlocale, right? What do
you think?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-08-25 00:34

Message:
Logged In: YES 
user_id=14198

Attached is a patch which names the new method
"locale._setlocale()"

An alternative and possibly better name would be
"getcrtlocale()" - any thoughts?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-24 20:24

Message:
Logged In: YES 
user_id=21627

I accept that in principle for _locale, unconditionally,
under a name different from "setlocale".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=776854&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 12:44:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 12:44:27 2004
Subject: [Patches] [ python-Patches-1015021 ] Docs claim that coerce can
	return None
Message-ID: 

Patches item #1015021, was opened at 2004-08-24 08:24
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015021&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docs claim that coerce can return None

Initial Comment:
The coerce builtin can't return None, but its docstring says
otherwise. As far back as I bothered to look (rev 2.98 of
bltnmodule.c in 1997), the implementation hasn't been able
to return None, so it's the docs that should be fixed.

Attached patch fixes the docstring and improves the library
reference to document what really happens if coercion fails.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 12:44

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

libfuncs.tex 1.174
bltinmodule.c 2.318
libfuncs.tex 1.143.8.12
bltinmodule.c 2.292.10.6


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015021&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 12:56:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 12:56:50 2004
Subject: [Patches] [ python-Patches-1014992 ] bug in
	tarfile.ExFileObject.readline
Message-ID: 

Patches item #1014992, was opened at 2004-08-24 06:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014992&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in tarfile.ExFileObject.readline

Initial Comment:
TarFile objects produce file-like objects to represent
internal files in the archive. There appears to be a
bug in the readline implementation for these objects.

When you specify the size parameter for readline, the
standard function will try to read one line with at
most size characters. However, in the tarfile module,
it may return extra data beyond the end of the line
(and also not clean out the trailing \r).

The problem is that after reading the maximum data, we
break out of the loop before checking for a newline.
This is fixed by modifying the while test.

This patch may break existing code which uses this
'feature'.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 12:56

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as tarfile.py 1.19 and
1.8.12.4, NEWS 1.831.4.148. I doubt this will break existing
code since people typically invoke readline without
arguments, and should expect that readline returns at most a
line - hence the backport to 2.3.

As for dealing with \r: patches to support universal
newlines would be welcome.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014992&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 13:06:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 13:07:04 2004
Subject: [Patches] [ python-Patches-796908 ] decode message attachments in
	email.Message
Message-ID: 

Patches item #796908, was opened at 2003-08-28 21:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796908&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Stuart D. Gathman (customdesigned)
Assigned to: Nobody/Anonymous (nobody)
Summary: decode message attachments in email.Message

Initial Comment:
This is a fix for bug 794458.  It is not a complete fix
because although it correctly decodes message
attachments on input, the Generator doesn't obey the
encoding.  I'll fix Generator.py next.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 13:06

Message:
Logged In: YES 
user_id=21627

The patch is out of date, as the code has been rewritten
since. Also, on the bug itself, Barry claims that this is
also out of date (i.e. fixed). So I'm rejecting this patch
as out-of-date also. If you disagree, please update the
patch, resubmit it, and include an test case that gets
corrected with your patch.

----------------------------------------------------------------------

Comment By: Stuart D. Gathman (customdesigned)
Date: 2003-09-08 22:00

Message:
Logged In: YES 
user_id=142072

I must have forgotten to check the checkbox . . .

It may not be necessary to modify Generator.  Any valid
rfc822 message 
would not need encoding as a message attachment.  If it is
desired to preserve the encoding, that is a simple patch to
Generator.py, and the Encoding would not be deleted as is
done in this patch.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-09-01 04:47

Message:
Logged In: YES 
user_id=2772

It looks like you failed to include the attachment/patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796908&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 13:25:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 13:25:07 2004
Subject: [Patches] [ python-Patches-798244 ] More urllib2 examples
Message-ID: 

Patches item #798244, was opened at 2003-08-31 21:47
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798244&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: More urllib2 examples

Initial Comment:
I'm posting this here because I couldn't see how to 
upload a file to bug 545480. 
 
Here are some more examples. 
 
I don't use a proxy, so I haven't tested them.  They're 
very simple though (famous last words...). 
 
I include examples about adding headers, since I get the 
impression people assume it's awkward to do this with 
urllib2.  Also, User-Agent is a special case that often 
comes up. 
 
The patch also fixes a couple of markup nits. 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 13:25

Message:
Logged In: YES 
user_id=21627

The examples look fine to me. Applied as urllib2.tex 1.21

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-01 01:56

Message:
Logged In: YES 
user_id=80475

Would you solicit someone to test these for you and report 
back when you're confident (based on running code) that 
they are right.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=798244&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 13:38:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 13:38:50 2004
Subject: [Patches] [ python-Patches-736857 ] interpreter final destination
	location
Message-ID: 

Patches item #736857, was opened at 2003-05-13 08:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736857&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Tim Magill (tmagill)
Assigned to: Nobody/Anonymous (nobody)
Summary: interpreter final destination location

Initial Comment:
New command line option to specify the string to be
substituted in the "#!" line at the beginning of scripts

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 13:38

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

build.py 1.35
build_scripts.py 1.24
NEWS 1.1111


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-16 07:44

Message:
Logged In: YES 
user_id=21627

As a new feature, I think it is too late to integrate it
into Python 2.3, so it should be postponed for now. I find
the feature itself relatively straight-forward to add it to
distutils.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736857&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 13:39:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 13:39:47 2004
Subject: [Patches] [ python-Patches-736859 ] docs for interpreter final
	destination location 
Message-ID: 

Patches item #736859, was opened at 2003-05-13 08:31
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736859&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Tim Magill (tmagill)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for interpreter final destination location 

Initial Comment:
documentation fragment for new command line option to
specify the string to be substituted in the "#!" line
at the beginning of scripts

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 13:39

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as 

dist.tex 1.85

In the future, proper patches for the documentation would be
appreciated, along with the code changes; you'll find the
source files of the documentation in the Doc directory of
the CVS tree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736859&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 15:01:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 15:01:41 2004
Subject: [Patches] [ python-Patches-970019 ] Use a better BuildRoot tag
Message-ID: 

Patches item #970019, was opened at 2004-06-10 01:44
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970019&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Scherer Michael (misc_from_metz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use a better BuildRoot tag

Initial Comment:
Using a Buildroot dependant only on the name can have some side effects.For example, two version of the same package cannot be build in parallel.
So, having BuildRoot : %{name}-%{version}-%{release} is safer.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 15:01

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as bdist_rpm.py 1.39, NEWS 1.1112.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970019&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 15:05:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 15:05:41 2004
Subject: [Patches] [ python-Patches-970015 ] Generate a working spec even
	with wrong version of software 
Message-ID: 

Patches item #970015, was opened at 2004-06-10 01:38
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970015&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Scherer Michael (misc_from_metz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generate a working spec even with wrong version of software 

Initial Comment:
Some python packages use a '-' in their version.
This doesn't work with rpm, since a tag Version cannot have a '-', this is the default separator between the release and version. A common practice for this problem is to change '-' by '_'.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 15:05

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as bdist_rpm.py 1.40, NEWS 1.1113.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970015&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 15:18:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 15:18:40 2004
Subject: [Patches] [ python-Patches-963906 ] Unicode email address helper
Message-ID: 

Patches item #963906, was opened at 2004-06-01 01:36
Message generated for change (Comment added) made by loewis
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: Martin v. L?wis (loewis)
Date: 2004-08-25 15: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  Wed Aug 25 15:19:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 15:19:57 2004
Subject: [Patches] [ python-Patches-963906 ] Unicode email address helper
Message-ID: 

Patches item #963906, was opened at 2004-06-01 01:36
Message generated for change (Comment added) made by loewis
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: Martin v. L?wis (loewis)
Date: 2004-08-25 15: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 15: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  Wed Aug 25 15:31:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 15:32:07 2004
Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy
Message-ID: 

Patches item #934711, was opened at 2004-04-14 06:05
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Trevor Perrin (trevp)
>Assigned to: Martin v. L?wis (loewis)
Summary: platform-specific entropy

Initial Comment:

This is a very simple module for accessing platform-
specific entropy sources.  

On Win32, it uses CryptGenRandom.  Otherwise, it tries 
to use /dev/urandom.  If it can't find that, it raises 
NotImplementedError.

>>> import entropy
>>> entropy.entropy(10)
'\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9'

To compile for Win32, you have to link with "advapi32".  
The /dev/urandom code has not been tested.

Issues:

 - I believe this works with all versions of Windows later 
than Win95.  But I'm not sure.

 - there's overhead in opening/closing the source.  On 
Win32 at least, opening it is slower than reading from it -
 it seems to take around 1/5th of a millisecond (i.e. I 
can make 5000 calls per second).  I think this is okay; 
you can make fewer calls and buffer the results, or seed 
your own PRNG.  However, we could make it more 
object-based, where you open an entropy-source, and 
then repeatedly read from it.

 - It would be nice if there was some attribute that told 
you what source you were using, so you could display 
it, and in case you trust /dev/urandom but not Win32's 
CryptoAPI, for example.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 15:31

Message:
Logged In: YES 
user_id=21627

I also like the patch, but I think a number of changes are
still needed:
- there is no documentation
- there are no test cases
- Don't use Py_BuildValue, use PyString_FromStringAndSize
instead
- Don't stat /dev/urandom when importing os, instead, stat
on first usage, and raise NotImplementedError if no source
of randomness can be found.

As an option, support for PRNG could be added (e.g. by
checking an environment variable), but that can be left to
anybody who actually has and needs PRNG.

As for leaving the fd open: this is ok, I think, if it isn't
opened until first use.

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-05-02 04:20

Message:
Logged In: YES 
user_id=499

This version looks exactly like what I need.  I really hope
it gets accepted for 2.4.

(I have no strong opinion on whether the fd/crypto context
should be held open.)

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-27 09:21

Message:
Logged In: YES 
user_id=973611

I'm uploading a 4th version that does this as an
"os.urandom()" function.  The win32 code is in
posixmodule.c, and the /dev/urandom code is in os.py.

I think the name "urandom" is better than "entropy" - to
some people, "entropy" sounds more like /dev/random. 
"urandom" makes it clear that we're trying to provide
/dev/urandom-like functionality across platforms (i.e.: try
to use real entropy, but if you have to stretch it with a
cryptographic PRNG that's okay).

Also, I cleaned up error-handling, so it will always return
OSError (or an OSError subclass, like WindowsError).  

Finally I changed it to open the random source once, instead
of re-opening it every call.  At least on windows this is a
big speedup - from being able to make 5K calls per second it
can now make 250K.  It's probable that people will write
crypto code using this as their sole RNG source, so this is
probably worthwhile.  This introduces a small risk of
leaking file descriptors/handles if the os module is
reloaded, but I think that's okay. 

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-26 19:11

Message:
Logged In: YES 
user_id=499

Your lastest version works fine for me (on Redhat Linux 9),
but I still think it would be a better idea to write the
/dev/urandom-ish code in Python, using os.open.  That way,
you could report better error messages if /dev/urandom is
inaccessable, instead of simply claiming that it "wasn't
found."  (Maybe it was found, but we don't have permission
to access it.)

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-26 05:53

Message:
Logged In: YES 
user_id=973611


> - I can't find a statement on the page you link about using
> CRYPT_VERIFYCONTEXT that way,

Note that retrying on NTE_BAD_KEYSET is only described under
the heading  "Private Key Operations Are Performed", in
which case you need to open/create a private key container.
 But if you use CRYPT_VERIFYCONTEXT it just creates a
temporary context in memory.  More corroboration:
http://tinyurl.com/2ct2o

For awhile I was distributing code without
CRYPT_VERIFYCONTEXT, and a user ran into the NTE_BAD_KEYSET
error.  But CRYPT_VERIFYCONTEXT fixed it, which is how I
stumbled on this...

> - One more important issue: It is a bad idea to use stdio
> (C's 'fopen', Python's builtin 'open') to read from
> /dev/urandom.

Good point.  I've tried to update the code to use syscalls.
 Is there any chance you could test this out, and see
whether the #includes look correct and portable?  I don't
have a UNIX box available.  If it needs fixes, feel free to
upload a new version.

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-26 02:49

Message:
Logged In: YES 
user_id=499

Thanks for the reply!

- As for /dev/*random -- yes, I believe you are right, and
/dev/urandom is almost always what you want.  I haven't been
able to find a platform that has one of the others, but
lacks /dev/urandom.

- I can't find a statement on the page you link about using
CRYPT_VERIFYCONTEXT that way, but you may well be right anway.

- One more important issue: It is a bad idea to use stdio
(C's 'fopen', Python's builtin 'open') to read from
/dev/urandom.  Most stdio implementation buffer data; on my
GNU/Linux box, when I call open('/dev/urandom').read(10), my
underlying fread() function sucks 4096 bytes into memory. 
(It does other weird stuff too, including calls to stat64,
mmap, and others.)  This has proved to be a problem in the
past, especially when running on systems with heavy user
process limits.  Instead, it is a better idea to use the
open syscall directly (open in C, os.open in Python).

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-26 02:08

Message:
Logged In: YES 
user_id=973611


Thanks for the comments! - 

> - According to MSDN, CryptGenRandom exists on Win98 and
> later, and on Win95 OSR2, and on Win95 with IE 3.something
> or later.

I'm uploading a new version that fails gracefully on old
Win95s (that's the only change).

> - It's necessary on some platforms, and for some
> applications, to use a device other than /dev/urandom. 
> (Some high-security code demands /dev/random; some 
> OpenBSD people swear by /dev/arandom; and so on.)

My understanding is that /dev/random should only be used in
exceptionally rare cases, if at all.  You can turn up
several posts by David Wagner, a respected cryptographer,
about this.  For example:
http://tinyurl.com/2z2fx

In any case, if you really want /dev/random, or one of the
OpenBSD variants (arandom, srandom, prandom, etc.), it's
easy to do it yourself: open("/dev/random").read().

So I think we should ignore these and stick with
/dev/urandom, since it's the easiest-to-use (non-blocking)
and most portable (unless there are systems that don't offer
it?).

> - Maybe it would be a good idea to only implement the
> windows CryptGenRandom part in C, and implement the Unix
> part in Python.

That's not a bad idea - I sorta think this function should
be placed in the 'os' module, instead of its own module.  So
we could put the /dev/urandom code in 'os.py', and allow
more specific code in, e.g., posixmodule.c to override it.  

We could also add a variable 'os.entropySource' which would
return '/dev/urandom', or 'CryptoAPI', or whatever.

> - According to the MSDN documentation for
> CryptAcquireContext, if your first call fails, you're
> supposed to retry with a final argument of 
> CRYPT_NEWKEYSET before you report an error.

I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the
need for that:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187








----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-25 20:55

Message:
Logged In: YES 
user_id=499

This patch would be tremendously valuable to me.  I've had
to maintain similar code for a couple of projects, and
having this functionality in Python would make my life one
step similar.

A few comments:
- According to MSDN, CryptGenRandom exists on Win98 and
later, and on Win95 OSR2, and on Win95 with IE 3.something
or later.

- It's necessary on some platforms, and for some
applications, to use a device other than /dev/urandom. 
(Some high-security code demands /dev/random; some OpenBSD
people swear by /dev/arandom; and so on.)

- Maybe it would be a good idea to only implement the
windows CryptGenRandom part in C, and implement the Unix
part in Python.  Then you could expose the windows code as
(say) "entopy.win_entropy(nBytes)", the unix part as (say)
"entropy.unix_entropy(nBytes, file='/dev/urandom')", and
have "entropy.entropy(nBytes)" be a cross-platform wrapper.
 This would cut down on the amount of C you need to add;
make it easier to switch entropy devices; provide better
errors when /dev/urandom is unreadable; and provide users
the option to trust only certain entropy sources.

- I believe that you're right not to worry too much about
the performance here.

- According to the MSDN documentation for
CryptAcquireContext, if your first call fails, you're
supposed to retry with a final argument of CRYPT_NEWKEYSET
before you report an error.  I don't know when/if this is
necessary, or whether there are hidden gotchas.

Once again, this patch is a great idea, and I heartily hope
that it gets in!

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-14 08:19

Message:
Logged In: YES 
user_id=973611

Just a thought - this might make sense as a function within 
the 'os' module, instead of its own module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 16:00:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 16:00:32 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 (Tracker Item Submitted) made by Item Submitter
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: Nobody/Anonymous (nobody)
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  Wed Aug 25 21:32:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 21:32:36 2004
Subject: [Patches] [ python-Patches-1016224 ] configure.in change to allow
	compilation on AIX 5
Message-ID: 

Patches item #1016224, was opened at 2004-08-25 19: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=1016224&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Martin v. L?wis (loewis)
Summary: configure.in change to allow compilation on AIX 5

Initial Comment:
A build of the current Python-CVS will fail on the
_bsddb module build (well, the _bsddb module build will
fail and the setup.py will ignore it and continue) on
AIX 5 with the following error:

    building '_bsddb' extension
    cc_r -DNDEBUG -O -I.../libprefix/include -I.
-I./Include -I.../python/Include -I.../python -c
.../python/Modules/_bsddb.c -o
build/temp.aix-5.1-2.4/_bsddb.o
    "./pyconfig.h", line 832.9: 1506-236 (W) Macro name
_XOPEN_SOURCE has been redefined.
    "./pyconfig.h", line 832.9: 1506-358 (I)
"_XOPEN_SOURCE" is defined on line 89 of
/usr/include/standards.h.
    "/usr/include/wchar.h", line 290.68: 1506-046 (S)
Syntax error. (wcsnrtombs)
    "/usr/include/wchar.h", line 293.68: 1506-046 (S)
Syntax error. (mbsnrtowcs)

error lines in /usr/include/wchar.h are the following:

    extern size_t wcsnrtombs(char *, const wchar_t **,
size_t, size_t, mbstate_t *);
    extern size_t mbsnrtowcs(wchar_t *, const char **,
size_t, size_t, mbstate_t *);

The problem is that mbstate_t is only defined if
_XOPEN_SOURCE is 500. Without the follow configure[.in]
change Python will define it to be 600.

This Python patch did the same thing for AIX 4:
   
http://sourceforge.net/tracker/index.php?func=detail&aid=836434&group_id=5470&atid=305470


I will upload a patch to configure.in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 21:52:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 21:52:23 2004
Subject: [Patches] [ python-Patches-1016224 ] configure.in change to allow
	compilation on AIX 5
Message-ID: 

Patches item #1016224, was opened at 2004-08-25 21:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Martin v. L?wis (loewis)
Summary: configure.in change to allow compilation on AIX 5

Initial Comment:
A build of the current Python-CVS will fail on the
_bsddb module build (well, the _bsddb module build will
fail and the setup.py will ignore it and continue) on
AIX 5 with the following error:

    building '_bsddb' extension
    cc_r -DNDEBUG -O -I.../libprefix/include -I.
-I./Include -I.../python/Include -I.../python -c
.../python/Modules/_bsddb.c -o
build/temp.aix-5.1-2.4/_bsddb.o
    "./pyconfig.h", line 832.9: 1506-236 (W) Macro name
_XOPEN_SOURCE has been redefined.
    "./pyconfig.h", line 832.9: 1506-358 (I)
"_XOPEN_SOURCE" is defined on line 89 of
/usr/include/standards.h.
    "/usr/include/wchar.h", line 290.68: 1506-046 (S)
Syntax error. (wcsnrtombs)
    "/usr/include/wchar.h", line 293.68: 1506-046 (S)
Syntax error. (mbsnrtowcs)

error lines in /usr/include/wchar.h are the following:

    extern size_t wcsnrtombs(char *, const wchar_t **,
size_t, size_t, mbstate_t *);
    extern size_t mbsnrtowcs(wchar_t *, const char **,
size_t, size_t, mbstate_t *);

The problem is that mbstate_t is only defined if
_XOPEN_SOURCE is 500. Without the follow configure[.in]
change Python will define it to be 600.

This Python patch did the same thing for AIX 4:
   
http://sourceforge.net/tracker/index.php?func=detail&aid=836434&group_id=5470&atid=305470


I will upload a patch to configure.in.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 21:52

Message:
Logged In: YES 
user_id=21627

It is (my) policy that work-arounds for bugs are only made
for systems that actually have the bugs. If you agree that
this entire thing is a bug in AIX (not being able to compile
its own headers if the user gives a #define that is meant to
be supported), then I'd like to encourage you to constrain
the work-around on those AIX5 releases where it shows up. If
it shows up on all AIX5 releases so far (which, AFAICT, is
5.1 .. 5.3), I'd still like to write 5.[123] rather than
presuming that the bug stays until AIX6.

The rationale for that procedure is that I want to take out
the work-arounds one day; for that to happen, we must need
to reevaluate the work-around for each OS release. Then, we
can unsupport older releases at some point, and eventually
remove work-arounds.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 22:17:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 22:17:40 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: Open
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-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 Aug 25 22:50:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 22:50:44 2004
Subject: [Patches] [ python-Patches-1016224 ] configure.in change to allow
	compilation on AIX 5
Message-ID: 

Patches item #1016224, was opened at 2004-08-25 19:32
Message generated for change (Comment added) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Martin v. L?wis (loewis)
Summary: configure.in change to allow compilation on AIX 5

Initial Comment:
A build of the current Python-CVS will fail on the
_bsddb module build (well, the _bsddb module build will
fail and the setup.py will ignore it and continue) on
AIX 5 with the following error:

    building '_bsddb' extension
    cc_r -DNDEBUG -O -I.../libprefix/include -I.
-I./Include -I.../python/Include -I.../python -c
.../python/Modules/_bsddb.c -o
build/temp.aix-5.1-2.4/_bsddb.o
    "./pyconfig.h", line 832.9: 1506-236 (W) Macro name
_XOPEN_SOURCE has been redefined.
    "./pyconfig.h", line 832.9: 1506-358 (I)
"_XOPEN_SOURCE" is defined on line 89 of
/usr/include/standards.h.
    "/usr/include/wchar.h", line 290.68: 1506-046 (S)
Syntax error. (wcsnrtombs)
    "/usr/include/wchar.h", line 293.68: 1506-046 (S)
Syntax error. (mbsnrtowcs)

error lines in /usr/include/wchar.h are the following:

    extern size_t wcsnrtombs(char *, const wchar_t **,
size_t, size_t, mbstate_t *);
    extern size_t mbsnrtowcs(wchar_t *, const char **,
size_t, size_t, mbstate_t *);

The problem is that mbstate_t is only defined if
_XOPEN_SOURCE is 500. Without the follow configure[.in]
change Python will define it to be 600.

This Python patch did the same thing for AIX 4:
   
http://sourceforge.net/tracker/index.php?func=detail&aid=836434&group_id=5470&atid=305470


I will upload a patch to configure.in.

----------------------------------------------------------------------

>Comment By: Trent Mick (tmick)
Date: 2004-08-25 20:50

Message:
Logged In: YES 
user_id=34892

That sounds good to me. My build machine is 5.1 so how about
this new patch (will attach).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 19:52

Message:
Logged In: YES 
user_id=21627

It is (my) policy that work-arounds for bugs are only made
for systems that actually have the bugs. If you agree that
this entire thing is a bug in AIX (not being able to compile
its own headers if the user gives a #define that is meant to
be supported), then I'd like to encourage you to constrain
the work-around on those AIX5 releases where it shows up. If
it shows up on all AIX5 releases so far (which, AFAICT, is
5.1 .. 5.3), I'd still like to write 5.[123] rather than
presuming that the bug stays until AIX6.

The rationale for that procedure is that I want to take out
the work-arounds one day; for that to happen, we must need
to reevaluate the work-around for each OS release. Then, we
can unsupport older releases at some point, and eventually
remove work-arounds.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470
From noreply at sourceforge.net  Wed Aug 25 23:59:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Aug 25 23:59:20 2004
Subject: [Patches] [ python-Patches-1016224 ] configure.in change to allow
	compilation on AIX 5
Message-ID: 

Patches item #1016224, was opened at 2004-08-25 21:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Trent Mick (tmick)
>Assigned to: Trent Mick (tmick)
Summary: configure.in change to allow compilation on AIX 5

Initial Comment:
A build of the current Python-CVS will fail on the
_bsddb module build (well, the _bsddb module build will
fail and the setup.py will ignore it and continue) on
AIX 5 with the following error:

    building '_bsddb' extension
    cc_r -DNDEBUG -O -I.../libprefix/include -I.
-I./Include -I.../python/Include -I.../python -c
.../python/Modules/_bsddb.c -o
build/temp.aix-5.1-2.4/_bsddb.o
    "./pyconfig.h", line 832.9: 1506-236 (W) Macro name
_XOPEN_SOURCE has been redefined.
    "./pyconfig.h", line 832.9: 1506-358 (I)
"_XOPEN_SOURCE" is defined on line 89 of
/usr/include/standards.h.
    "/usr/include/wchar.h", line 290.68: 1506-046 (S)
Syntax error. (wcsnrtombs)
    "/usr/include/wchar.h", line 293.68: 1506-046 (S)
Syntax error. (mbsnrtowcs)

error lines in /usr/include/wchar.h are the following:

    extern size_t wcsnrtombs(char *, const wchar_t **,
size_t, size_t, mbstate_t *);
    extern size_t mbsnrtowcs(wchar_t *, const char **,
size_t, size_t, mbstate_t *);

The problem is that mbstate_t is only defined if
_XOPEN_SOURCE is 500. Without the follow configure[.in]
change Python will define it to be 600.

This Python patch did the same thing for AIX 4:
   
http://sourceforge.net/tracker/index.php?func=detail&aid=836434&group_id=5470&atid=305470


I will upload a patch to configure.in.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 23:59

Message:
Logged In: YES 
user_id=21627

This is fine, please apply.

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2004-08-25 22:50

Message:
Logged In: YES 
user_id=34892

That sounds good to me. My build machine is 5.1 so how about
this new patch (will attach).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 21:52

Message:
Logged In: YES 
user_id=21627

It is (my) policy that work-arounds for bugs are only made
for systems that actually have the bugs. If you agree that
this entire thing is a bug in AIX (not being able to compile
its own headers if the user gives a #define that is meant to
be supported), then I'd like to encourage you to constrain
the work-around on those AIX5 releases where it shows up. If
it shows up on all AIX5 releases so far (which, AFAICT, is
5.1 .. 5.3), I'd still like to write 5.[123] rather than
presuming that the bug stays until AIX6.

The rationale for that procedure is that I want to take out
the work-arounds one day; for that to happen, we must need
to reevaluate the work-around for each OS release. Then, we
can unsupport older releases at some point, and eventually
remove work-arounds.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 00:59:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 00:59:32 2004
Subject: [Patches] [ python-Patches-776854 ] expose lowlevel setlocale
Message-ID: 

Patches item #776854, was opened at 2003-07-24 20:17
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=776854&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: expose lowlevel setlocale

Initial Comment:
I propose (for post 2.3) we expose a lowlevel
setlocale() for diagnostic purposes.  Specifically, I
propose that release builds support only querying the
current locale, but Py_DEBUG builds be capable of
bypassing Python completely.

This is somewhat complementary to [ 774665 ] making
Python LC_NUMERIC agnostic

This would be extremely good for Windows - hence my
patch adds such a method to the "msvcrt" module. 
However, I believe it worthy of consideration for
locale itself, seeing as it is impossible to have
Python-related side effects in release builds.  For
people running debug builds (or capable of switching to
them) it provides invaluable help.

Assigning to Tim to pronounce on.  Either reject it,
accept for msvcrt (and I will check it in post 1.3) or
accept in principle for _locale, then assign back.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-08-26 08:59

Message:
Logged In: YES 
user_id=14198

Thanks Martin - so similar in fact that it is no longer
needed!  You revision 2.46 "Patch #774665: Make Python
LC_NUMERIC agnostic." provides the same basic functionality.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 15:51

Message:
Logged In: YES 
user_id=21627

AFAICT, the only change left between this function and
_locale.setlocale is that the latter also adjusts
string.upper etc. I wonder whether we should take this code
out of _localemodule.c, and move it into locale.py. In that
case, you could just use _locale.setlocale, right? What do
you think?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-08-25 08:34

Message:
Logged In: YES 
user_id=14198

Attached is a patch which names the new method
"locale._setlocale()"

An alternative and possibly better name would be
"getcrtlocale()" - any thoughts?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-25 04:24

Message:
Logged In: YES 
user_id=21627

I accept that in principle for _locale, unconditionally,
under a name different from "setlocale".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=776854&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 01:35:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 01:35:47 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02:44
Message generated for change (Settings changed) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
>Assigned to: Dave Cole (davecole)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:45

Message:
Logged In: YES 
user_id=908995

The patch looks good to me after a quick glance and test
run. Maybe add something to the test suite to exercise these
attributes? It should be as easy as adding print statements
to a handler or two (the test relies heavily on comparing
the output to a known one). Most of the other attributes
aren't tested-for by the test suite, though. \versionadded
in the docs might be nice, too--just once, after the
paragraph introducing them.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-24 02:47

Message:
Logged In: YES 
user_id=28658

Oops - obviously CurrentColumnNumber wraps
XML_GetCurrentColumnNumber, and CurrentLineNumber wraps
XML_GetCurrentLineNumber.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 02:01:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 02:01:08 2004
Subject: [Patches] [ python-Patches-1016224 ] configure.in change to allow
	compilation on AIX 5
Message-ID: 

Patches item #1016224, was opened at 2004-08-25 19:32
Message generated for change (Comment added) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Trent Mick (tmick)
Summary: configure.in change to allow compilation on AIX 5

Initial Comment:
A build of the current Python-CVS will fail on the
_bsddb module build (well, the _bsddb module build will
fail and the setup.py will ignore it and continue) on
AIX 5 with the following error:

    building '_bsddb' extension
    cc_r -DNDEBUG -O -I.../libprefix/include -I.
-I./Include -I.../python/Include -I.../python -c
.../python/Modules/_bsddb.c -o
build/temp.aix-5.1-2.4/_bsddb.o
    "./pyconfig.h", line 832.9: 1506-236 (W) Macro name
_XOPEN_SOURCE has been redefined.
    "./pyconfig.h", line 832.9: 1506-358 (I)
"_XOPEN_SOURCE" is defined on line 89 of
/usr/include/standards.h.
    "/usr/include/wchar.h", line 290.68: 1506-046 (S)
Syntax error. (wcsnrtombs)
    "/usr/include/wchar.h", line 293.68: 1506-046 (S)
Syntax error. (mbsnrtowcs)

error lines in /usr/include/wchar.h are the following:

    extern size_t wcsnrtombs(char *, const wchar_t **,
size_t, size_t, mbstate_t *);
    extern size_t mbsnrtowcs(wchar_t *, const char **,
size_t, size_t, mbstate_t *);

The problem is that mbstate_t is only defined if
_XOPEN_SOURCE is 500. Without the follow configure[.in]
change Python will define it to be 600.

This Python patch did the same thing for AIX 4:
   
http://sourceforge.net/tracker/index.php?func=detail&aid=836434&group_id=5470&atid=305470


I will upload a patch to configure.in.

----------------------------------------------------------------------

>Comment By: Trent Mick (tmick)
Date: 2004-08-26 00:01

Message:
Logged In: YES 
user_id=34892

Checked in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 21:59

Message:
Logged In: YES 
user_id=21627

This is fine, please apply.

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2004-08-25 20:50

Message:
Logged In: YES 
user_id=34892

That sounds good to me. My build machine is 5.1 so how about
this new patch (will attach).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 19:52

Message:
Logged In: YES 
user_id=21627

It is (my) policy that work-arounds for bugs are only made
for systems that actually have the bugs. If you agree that
this entire thing is a bug in AIX (not being able to compile
its own headers if the user gives a #define that is meant to
be supported), then I'd like to encourage you to constrain
the work-around on those AIX5 releases where it shows up. If
it shows up on all AIX5 releases so far (which, AFAICT, is
5.1 .. 5.3), I'd still like to write 5.[123] rather than
presuming that the bug stays until AIX6.

The rationale for that procedure is that I want to take out
the work-arounds one day; for that to happen, we must need
to reevaluate the work-around for each OS release. Then, we
can unsupport older releases at some point, and eventually
remove work-arounds.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 02:01:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 02:01:23 2004
Subject: [Patches] [ python-Patches-1016224 ] configure.in change to allow
	compilation on AIX 5
Message-ID: 

Patches item #1016224, was opened at 2004-08-25 19:32
Message generated for change (Settings changed) made by tmick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Trent Mick (tmick)
Assigned to: Trent Mick (tmick)
Summary: configure.in change to allow compilation on AIX 5

Initial Comment:
A build of the current Python-CVS will fail on the
_bsddb module build (well, the _bsddb module build will
fail and the setup.py will ignore it and continue) on
AIX 5 with the following error:

    building '_bsddb' extension
    cc_r -DNDEBUG -O -I.../libprefix/include -I.
-I./Include -I.../python/Include -I.../python -c
.../python/Modules/_bsddb.c -o
build/temp.aix-5.1-2.4/_bsddb.o
    "./pyconfig.h", line 832.9: 1506-236 (W) Macro name
_XOPEN_SOURCE has been redefined.
    "./pyconfig.h", line 832.9: 1506-358 (I)
"_XOPEN_SOURCE" is defined on line 89 of
/usr/include/standards.h.
    "/usr/include/wchar.h", line 290.68: 1506-046 (S)
Syntax error. (wcsnrtombs)
    "/usr/include/wchar.h", line 293.68: 1506-046 (S)
Syntax error. (mbsnrtowcs)

error lines in /usr/include/wchar.h are the following:

    extern size_t wcsnrtombs(char *, const wchar_t **,
size_t, size_t, mbstate_t *);
    extern size_t mbsnrtowcs(wchar_t *, const char **,
size_t, size_t, mbstate_t *);

The problem is that mbstate_t is only defined if
_XOPEN_SOURCE is 500. Without the follow configure[.in]
change Python will define it to be 600.

This Python patch did the same thing for AIX 4:
   
http://sourceforge.net/tracker/index.php?func=detail&aid=836434&group_id=5470&atid=305470


I will upload a patch to configure.in.

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2004-08-26 00:01

Message:
Logged In: YES 
user_id=34892

Checked in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 21:59

Message:
Logged In: YES 
user_id=21627

This is fine, please apply.

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2004-08-25 20:50

Message:
Logged In: YES 
user_id=34892

That sounds good to me. My build machine is 5.1 so how about
this new patch (will attach).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 19:52

Message:
Logged In: YES 
user_id=21627

It is (my) policy that work-arounds for bugs are only made
for systems that actually have the bugs. If you agree that
this entire thing is a bug in AIX (not being able to compile
its own headers if the user gives a #define that is meant to
be supported), then I'd like to encourage you to constrain
the work-around on those AIX5 releases where it shows up. If
it shows up on all AIX5 releases so far (which, AFAICT, is
5.1 .. 5.3), I'd still like to write 5.[123] rather than
presuming that the bug stays until AIX6.

The rationale for that procedure is that I want to take out
the work-arounds one day; for that to happen, we must need
to reevaluate the work-around for each OS release. Then, we
can unsupport older releases at some point, and eventually
remove work-arounds.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1016224&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 02:35:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 02:35:35 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02:44
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-26 00:35

Message:
Logged In: YES 
user_id=28658

Have added a unit test to check that the Current* members do
return something useful for parser events.  Decided against
testing character data events as there can be more than one
per section of character data - this might be fragile in the
face of newer expat versions.

Oh, also added a \versionadded.  Will apply this patch.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:45

Message:
Logged In: YES 
user_id=908995

The patch looks good to me after a quick glance and test
run. Maybe add something to the test suite to exercise these
attributes? It should be as easy as adding print statements
to a handler or two (the test relies heavily on comparing
the output to a known one). Most of the other attributes
aren't tested-for by the test suite, though. \versionadded
in the docs might be nice, too--just once, after the
paragraph introducing them.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-24 02:47

Message:
Logged In: YES 
user_id=28658

Oops - obviously CurrentColumnNumber wraps
XML_GetCurrentColumnNumber, and CurrentLineNumber wraps
XML_GetCurrentLineNumber.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 02:41:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 02:41:42 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02:44
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-26 00:41

Message:
Logged In: YES 
user_id=28658

Patch applied:
Doc/lib/libpyexpat.tex; new revision: 1.24
Lib/test/test_pyexpat.py; new revision: 1.16
Misc/NEWS; new revision: 1.1114
Modules/pyexpat.c; new revision: 2.88


----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-26 00:35

Message:
Logged In: YES 
user_id=28658

Have added a unit test to check that the Current* members do
return something useful for parser events.  Decided against
testing character data events as there can be more than one
per section of character data - this might be fragile in the
face of newer expat versions.

Oh, also added a \versionadded.  Will apply this patch.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:45

Message:
Logged In: YES 
user_id=908995

The patch looks good to me after a quick glance and test
run. Maybe add something to the test suite to exercise these
attributes? It should be as easy as adding print statements
to a handler or two (the test relies heavily on comparing
the output to a known one). Most of the other attributes
aren't tested-for by the test suite, though. \versionadded
in the docs might be nice, too--just once, after the
paragraph introducing them.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-24 02:47

Message:
Logged In: YES 
user_id=28658

Oops - obviously CurrentColumnNumber wraps
XML_GetCurrentColumnNumber, and CurrentLineNumber wraps
XML_GetCurrentLineNumber.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 02:42:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 02:42:09 2004
Subject: [Patches] [ python-Patches-1014930 ] Expose current parse location
	to XMLParser
Message-ID: 

Patches item #1014930, was opened at 2004-08-24 02:44
Message generated for change (Settings changed) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470

Category: XML
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Dave Cole (davecole)
Assigned to: Dave Cole (davecole)
Summary: Expose current parse location to XMLParser

Initial Comment:
This patch adds CurrentByteIndex, CurrentColumnNumber,
CurrentLineNumber members to the
xml.parsers.expat.XMLParser object which respectively
wrap the XML_GetCurrentByteIndex,
XML_GetCurrentLineNumber, and
XML_GetCurrentColumnNumber expat functions.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-26 00:41

Message:
Logged In: YES 
user_id=28658

Patch applied:
Doc/lib/libpyexpat.tex; new revision: 1.24
Lib/test/test_pyexpat.py; new revision: 1.16
Misc/NEWS; new revision: 1.1114
Modules/pyexpat.c; new revision: 2.88


----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-26 00:35

Message:
Logged In: YES 
user_id=28658

Have added a unit test to check that the Current* members do
return something useful for parser events.  Decided against
testing character data events as there can be more than one
per section of character data - this might be fragile in the
face of newer expat versions.

Oh, also added a \versionadded.  Will apply this patch.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:45

Message:
Logged In: YES 
user_id=908995

The patch looks good to me after a quick glance and test
run. Maybe add something to the test suite to exercise these
attributes? It should be as easy as adding print statements
to a handler or two (the test relies heavily on comparing
the output to a known one). Most of the other attributes
aren't tested-for by the test suite, though. \versionadded
in the docs might be nice, too--just once, after the
paragraph introducing them.

----------------------------------------------------------------------

Comment By: Dave Cole (davecole)
Date: 2004-08-24 02:47

Message:
Logged In: YES 
user_id=28658

Oops - obviously CurrentColumnNumber wraps
XML_GetCurrentColumnNumber, and CurrentLineNumber wraps
XML_GetCurrentLineNumber.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1014930&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 02:52:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 02:52:45 2004
Subject: [Patches] [ python-Patches-1015012 ] Improve markup and punctuation
	in libsocket.tex
Message-ID: 

Patches item #1015012, was opened at 2004-08-24 05:57
Message generated for change (Comment added) made by davecole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Dave Cole (davecole)
Summary: Improve markup and punctuation in libsocket.tex

Initial Comment:
- Use \constant around AF_* constants
- Avoid comma splice

----------------------------------------------------------------------

>Comment By: Dave Cole (davecole)
Date: 2004-08-26 00:52

Message:
Logged In: YES 
user_id=28658

Applied patch
Doc/lib/libsocket.tex; new revision: 1.88
Modules/socketmodule.c; new revision: 1.304


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:07

Message:
Logged In: YES 
user_id=908995

Assigned to davecole since he added socketpair

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 06:06

Message:
Logged In: YES 
user_id=908995

Might as well fix the docstring as well while I'm picking nits. Uploaded 
new patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015012&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 07:36:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 07:36:04 2004
Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug
	925628)
Message-ID: 

Patches item #934356, was opened at 2004-04-13 13:02
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help on re-exported names (bug 925628)

Initial Comment:
help(module) only provides help on classes and functions 
that were first defined within the module.  For wrapper 
modules (like re), or partially-in-C modules (like socket)
this is not helpful.

The following patch changes pydoc(module) to document 
exactly the names listed in __all__, with a fallback to the 
current choices if __all__ is not defined.


----------------------------------------------------------------------

>Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-26 01:36

Message:
Logged In: YES 
user_id=764593

Yes, the earlier patch fixes most of this, and cleans up the 
remainder.  The only thing left is to make sure visiblename 
gets called on even imported objects.

Style question:  Should I use "if all" or "if all is not None".  

The only time it would make a difference is with an 
unusual imported special name.  (__*__, but not 
__builtins__, __doc__, __file__, __path__, __module__, 
or __name__).

Given that all has been bound to object.__all__ (or to 
None, in case of AttributeError), should I

(1)  Use "if all is not None or ..." to emphasize that I'm 
avoiding a special case (__all__ not defined) or
(2)  Use "if all or ..." because it is shorter


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 07:46

Message:
Logged In: YES 
user_id=469548

Right now all four hunks of the patch are failing for me
(probably because of #969938, which fixes part of the
problem). Could you update the patch to CVS HEAD and assign
to me afterwards? I'll take a good look at it then.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-16 16:23

Message:
Logged In: YES 
user_id=764593

Replacing with an improved version.  This is a diff to CVS 
head; users of Python 2.3 would have to either change the 
line numbers or also replace collections.deque.  (Setting deque 
to list was enough to allow testing.)

[Original patch had a problem with normal modules, but the 
exception was caught at a higher level, and *something* 
returned, so I didn't notice it at first.]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 09:07:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 09:07:08 2004
Subject: [Patches] [ python-Patches-970288 ] Fix for #876637 - Random stack
	corruption from socketmodule
Message-ID: 

Patches item #970288, was opened at 2004-06-10 13:13
Message generated for change (Comment added) made by troels
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Troels Walsted Hansen (troels)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for #876637 - Random stack corruption from socketmodule

Initial Comment:
Here's a patch to convert socketmodule to use poll()
for the timeout handling.

ifdefs and includes have been copied from selectmodule,
so I believe they should be correct for all platforms.

Compiled and tested on Linux (RH73).


----------------------------------------------------------------------

>Comment By: Troels Walsted Hansen (troels)
Date: 2004-08-26 09:07

Message:
Logged In: YES 
user_id=32863

You're right, however I think that it is a very minor
problem compared to the current situation. All major UNIX
platforms support poll(2) in my experience. The only
important Python platform without poll is Windows, and it
doesn't have the FD_SETSIZE problem.

Thus I think the patch should be applied as it stands, but
the original bug ticket can be left open for another
enterprising individual to make the changes you suggest.

I'm afraid that work commitments prevent me from being that
individual for the foreseeable future...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 18:30

Message:
Logged In: YES 
user_id=21627

While the patch is good as it stands, it is also incomplete:
If poll(2) is not available, it might still overrun the
FD_SETSIZE. I think there should be another return value
from internal_select (-1), indicating an internal error. A
Python RuntimeError should be set in this case. Callers
should check for -1, and return immediately.

Are you willing to extend the patch in that direction?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 10:53:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 10:53:26 2004
Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy
Message-ID: 

Patches item #934711, was opened at 2004-04-13 21:05
Message generated for change (Comment added) made by trevp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Trevor Perrin (trevp)
Assigned to: Martin v. L?wis (loewis)
Summary: platform-specific entropy

Initial Comment:

This is a very simple module for accessing platform-
specific entropy sources.  

On Win32, it uses CryptGenRandom.  Otherwise, it tries 
to use /dev/urandom.  If it can't find that, it raises 
NotImplementedError.

>>> import entropy
>>> entropy.entropy(10)
'\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9'

To compile for Win32, you have to link with "advapi32".  
The /dev/urandom code has not been tested.

Issues:

 - I believe this works with all versions of Windows later 
than Win95.  But I'm not sure.

 - there's overhead in opening/closing the source.  On 
Win32 at least, opening it is slower than reading from it -
 it seems to take around 1/5th of a millisecond (i.e. I 
can make 5000 calls per second).  I think this is okay; 
you can make fewer calls and buffer the results, or seed 
your own PRNG.  However, we could make it more 
object-based, where you open an entropy-source, and 
then repeatedly read from it.

 - It would be nice if there was some attribute that told 
you what source you were using, so you could display 
it, and in case you trust /dev/urandom but not Win32's 
CryptoAPI, for example.

----------------------------------------------------------------------

>Comment By: Trevor Perrin (trevp)
Date: 2004-08-26 01:53

Message:
Logged In: YES 
user_id=973611

Hi Martin,

Thanks for looking at this.  I uploaded a new patch (5th
version) with docs, tests, and your suggestions.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 06:31

Message:
Logged In: YES 
user_id=21627

I also like the patch, but I think a number of changes are
still needed:
- there is no documentation
- there are no test cases
- Don't use Py_BuildValue, use PyString_FromStringAndSize
instead
- Don't stat /dev/urandom when importing os, instead, stat
on first usage, and raise NotImplementedError if no source
of randomness can be found.

As an option, support for PRNG could be added (e.g. by
checking an environment variable), but that can be left to
anybody who actually has and needs PRNG.

As for leaving the fd open: this is ok, I think, if it isn't
opened until first use.

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-05-01 19:20

Message:
Logged In: YES 
user_id=499

This version looks exactly like what I need.  I really hope
it gets accepted for 2.4.

(I have no strong opinion on whether the fd/crypto context
should be held open.)

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-27 00:21

Message:
Logged In: YES 
user_id=973611

I'm uploading a 4th version that does this as an
"os.urandom()" function.  The win32 code is in
posixmodule.c, and the /dev/urandom code is in os.py.

I think the name "urandom" is better than "entropy" - to
some people, "entropy" sounds more like /dev/random. 
"urandom" makes it clear that we're trying to provide
/dev/urandom-like functionality across platforms (i.e.: try
to use real entropy, but if you have to stretch it with a
cryptographic PRNG that's okay).

Also, I cleaned up error-handling, so it will always return
OSError (or an OSError subclass, like WindowsError).  

Finally I changed it to open the random source once, instead
of re-opening it every call.  At least on windows this is a
big speedup - from being able to make 5K calls per second it
can now make 250K.  It's probable that people will write
crypto code using this as their sole RNG source, so this is
probably worthwhile.  This introduces a small risk of
leaking file descriptors/handles if the os module is
reloaded, but I think that's okay. 

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-26 10:11

Message:
Logged In: YES 
user_id=499

Your lastest version works fine for me (on Redhat Linux 9),
but I still think it would be a better idea to write the
/dev/urandom-ish code in Python, using os.open.  That way,
you could report better error messages if /dev/urandom is
inaccessable, instead of simply claiming that it "wasn't
found."  (Maybe it was found, but we don't have permission
to access it.)

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-25 20:53

Message:
Logged In: YES 
user_id=973611


> - I can't find a statement on the page you link about using
> CRYPT_VERIFYCONTEXT that way,

Note that retrying on NTE_BAD_KEYSET is only described under
the heading  "Private Key Operations Are Performed", in
which case you need to open/create a private key container.
 But if you use CRYPT_VERIFYCONTEXT it just creates a
temporary context in memory.  More corroboration:
http://tinyurl.com/2ct2o

For awhile I was distributing code without
CRYPT_VERIFYCONTEXT, and a user ran into the NTE_BAD_KEYSET
error.  But CRYPT_VERIFYCONTEXT fixed it, which is how I
stumbled on this...

> - One more important issue: It is a bad idea to use stdio
> (C's 'fopen', Python's builtin 'open') to read from
> /dev/urandom.

Good point.  I've tried to update the code to use syscalls.
 Is there any chance you could test this out, and see
whether the #includes look correct and portable?  I don't
have a UNIX box available.  If it needs fixes, feel free to
upload a new version.

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-25 17:49

Message:
Logged In: YES 
user_id=499

Thanks for the reply!

- As for /dev/*random -- yes, I believe you are right, and
/dev/urandom is almost always what you want.  I haven't been
able to find a platform that has one of the others, but
lacks /dev/urandom.

- I can't find a statement on the page you link about using
CRYPT_VERIFYCONTEXT that way, but you may well be right anway.

- One more important issue: It is a bad idea to use stdio
(C's 'fopen', Python's builtin 'open') to read from
/dev/urandom.  Most stdio implementation buffer data; on my
GNU/Linux box, when I call open('/dev/urandom').read(10), my
underlying fread() function sucks 4096 bytes into memory. 
(It does other weird stuff too, including calls to stat64,
mmap, and others.)  This has proved to be a problem in the
past, especially when running on systems with heavy user
process limits.  Instead, it is a better idea to use the
open syscall directly (open in C, os.open in Python).

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-25 17:08

Message:
Logged In: YES 
user_id=973611


Thanks for the comments! - 

> - According to MSDN, CryptGenRandom exists on Win98 and
> later, and on Win95 OSR2, and on Win95 with IE 3.something
> or later.

I'm uploading a new version that fails gracefully on old
Win95s (that's the only change).

> - It's necessary on some platforms, and for some
> applications, to use a device other than /dev/urandom. 
> (Some high-security code demands /dev/random; some 
> OpenBSD people swear by /dev/arandom; and so on.)

My understanding is that /dev/random should only be used in
exceptionally rare cases, if at all.  You can turn up
several posts by David Wagner, a respected cryptographer,
about this.  For example:
http://tinyurl.com/2z2fx

In any case, if you really want /dev/random, or one of the
OpenBSD variants (arandom, srandom, prandom, etc.), it's
easy to do it yourself: open("/dev/random").read().

So I think we should ignore these and stick with
/dev/urandom, since it's the easiest-to-use (non-blocking)
and most portable (unless there are systems that don't offer
it?).

> - Maybe it would be a good idea to only implement the
> windows CryptGenRandom part in C, and implement the Unix
> part in Python.

That's not a bad idea - I sorta think this function should
be placed in the 'os' module, instead of its own module.  So
we could put the /dev/urandom code in 'os.py', and allow
more specific code in, e.g., posixmodule.c to override it.  

We could also add a variable 'os.entropySource' which would
return '/dev/urandom', or 'CryptoAPI', or whatever.

> - According to the MSDN documentation for
> CryptAcquireContext, if your first call fails, you're
> supposed to retry with a final argument of 
> CRYPT_NEWKEYSET before you report an error.

I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the
need for that:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187








----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-25 11:55

Message:
Logged In: YES 
user_id=499

This patch would be tremendously valuable to me.  I've had
to maintain similar code for a couple of projects, and
having this functionality in Python would make my life one
step similar.

A few comments:
- According to MSDN, CryptGenRandom exists on Win98 and
later, and on Win95 OSR2, and on Win95 with IE 3.something
or later.

- It's necessary on some platforms, and for some
applications, to use a device other than /dev/urandom. 
(Some high-security code demands /dev/random; some OpenBSD
people swear by /dev/arandom; and so on.)

- Maybe it would be a good idea to only implement the
windows CryptGenRandom part in C, and implement the Unix
part in Python.  Then you could expose the windows code as
(say) "entopy.win_entropy(nBytes)", the unix part as (say)
"entropy.unix_entropy(nBytes, file='/dev/urandom')", and
have "entropy.entropy(nBytes)" be a cross-platform wrapper.
 This would cut down on the amount of C you need to add;
make it easier to switch entropy devices; provide better
errors when /dev/urandom is unreadable; and provide users
the option to trust only certain entropy sources.

- I believe that you're right not to worry too much about
the performance here.

- According to the MSDN documentation for
CryptAcquireContext, if your first call fails, you're
supposed to retry with a final argument of CRYPT_NEWKEYSET
before you report an error.  I don't know when/if this is
necessary, or whether there are hidden gotchas.

Once again, this patch is a great idea, and I heartily hope
that it gets in!

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-13 23:19

Message:
Logged In: YES 
user_id=973611

Just a thought - this might make sense as a function within 
the 'os' module, instead of its own module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 18:13:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 18:13:38 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: Open
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-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  Thu Aug 26 18:19:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 18:19:34 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: Open
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-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  Thu Aug 26 23:50:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 23:51:08 2004
Subject: [Patches] [ python-Patches-1001610 ] socketmodule on
	OpenBSD/sparc64 (64bit machine)
Message-ID: 

Patches item #1001610, was opened at 2004-08-01 21:33
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001610&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Aleksander Piotrowski (pelotas)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule on OpenBSD/sparc64 (64bit machine)

Initial Comment:
In revision 1.280 of Modules/socketmodule.c, perky has
fixed some problems of socketmodule on 64bit arches. On
my OpenBSD/sparc64 (SUN Ultra 10) this change is not
enough. Attached patch (which is currently part of
python port for OpenBSD) is necessary.

In private mail, perky said that this change might be
OK for OpenBSD but doesn't work for other OSes.

Attached diff is against 2.3.4.

BTW this another unsigned long to int change doesn't
break OpenBSD/i386.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-26 23:50

Message:
Logged In: YES 
user_id=21627

Rejecting the patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-02 01:11

Message:
Logged In: YES 
user_id=21627

This patch is incorrect. On your system, I believe,
inet_addr does not return int, but in_addr_t. Therefore, you
should write an autoconf test that tests whether in_addr_t
is available on the system. If the type is not available,
check whether unsigned long int has size 4. If it doesn't,
check whether unsigned int has size 4. Of these three types,
use the first one that matches; generate an #error if you
can't find a suitable type.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001610&group_id=5470
From noreply at sourceforge.net  Thu Aug 26 23:57:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Aug 26 23:58:06 2004
Subject: [Patches] [ python-Patches-1003535 ] Simple File fix for Windows
	Runtime incompatability
Message-ID: 

Patches item #1003535, was opened at 2004-08-04 22:17
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003535&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Schwartz (mdjeremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simple File fix for Windows Runtime incompatability

Initial Comment:

Problem:

PyRun_SimpleFile - Using this function on Windows with
MSVC7 (VS .NET) causes a crash.

Reason: 

1)Pre built binaries link to msvcrt.dll. New version of
MSVC link to msvcrt71.dll. The FILE structure is
different across the two versions of runtime library. 

2) If python23.dll is rebuilt using the latest binary,
and issue exist where passing in FILE * still causes
the runtime library to throw an exception due to
running in the dll's context.

Solution:

Remove both of these problems by adding a new function
that only takes the filename (future maybe fopen flags)
and have the dll open the file itself and pass it on.

New function added to pythonrun.c and pythonrun.h

int
PyRun_SimpleFileWithOpen(const char *filename)

Takes just the file name, opens the file and then pass
it on.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-26 23:57

Message:
Logged In: YES 
user_id=21627

I would like to see the following changes to the patch:
- remove all parts that are not strictly relevant (IOW, make
it minimal)
- call the function PyRun_SimpleFileName
- Add a PyCompilerFlags*. If you want to, you can allow this
argument to be NULL.
- Add a PyRun_SimpleParseFileName parallel function, and
PyRun_FileName
  (i.e. all File APIs except for Any, which supports
terminals and is irrelevant here)
- Provide documentation patches as well.

Are you willing to carry out these changes?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-09 02:40

Message:
Logged In: YES 
user_id=31435

There appear to be all sorts of things in the patch that don't 
have anything to do with the new function.  Is that 
intentional?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003535&group_id=5470
From noreply at sourceforge.net  Fri Aug 27 03:25:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 27 03:25:20 2004
Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug
	925628)
Message-ID: 

Patches item #934356, was opened at 2004-04-13 13:02
Message generated for change (Settings changed) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: help on re-exported names (bug 925628)

Initial Comment:
help(module) only provides help on classes and functions 
that were first defined within the module.  For wrapper 
modules (like re), or partially-in-C modules (like socket)
this is not helpful.

The following patch changes pydoc(module) to document 
exactly the names listed in __all__, with a fallback to the 
current choices if __all__ is not defined.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-26 01:36

Message:
Logged In: YES 
user_id=764593

Yes, the earlier patch fixes most of this, and cleans up the 
remainder.  The only thing left is to make sure visiblename 
gets called on even imported objects.

Style question:  Should I use "if all" or "if all is not None".  

The only time it would make a difference is with an 
unusual imported special name.  (__*__, but not 
__builtins__, __doc__, __file__, __path__, __module__, 
or __name__).

Given that all has been bound to object.__all__ (or to 
None, in case of AttributeError), should I

(1)  Use "if all is not None or ..." to emphasize that I'm 
avoiding a special case (__all__ not defined) or
(2)  Use "if all or ..." because it is shorter


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 07:46

Message:
Logged In: YES 
user_id=469548

Right now all four hunks of the patch are failing for me
(probably because of #969938, which fixes part of the
problem). Could you update the patch to CVS HEAD and assign
to me afterwards? I'll take a good look at it then.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-16 16:23

Message:
Logged In: YES 
user_id=764593

Replacing with an improved version.  This is a diff to CVS 
head; users of Python 2.3 would have to either change the 
line numbers or also replace collections.deque.  (Setting deque 
to list was enough to allow testing.)

[Original patch had a problem with normal modules, but the 
exception was caught at a higher level, and *something* 
returned, so I didn't notice it at first.]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470
From noreply at sourceforge.net  Fri Aug 27 05:44:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 27 05:45:04 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-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  Fri Aug 27 08:01:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 27 08:01:20 2004
Subject: [Patches] [ python-Patches-1017405 ] bsddb's DB.keys() method
	ignores transaction argument
Message-ID: 

Patches item #1017405, was opened at 2004-08-27 02:01
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=1017405&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017405&group_id=5470
From noreply at sourceforge.net  Fri Aug 27 14:26:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 27 14:26:16 2004
Subject: [Patches] [ python-Patches-1017550 ] Fix for bug 1017546
Message-ID: 

Patches item #1017550, was opened at 2004-08-27 13:26
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=1017550&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael (ms_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug 1017546

Initial Comment:
Attached patch is against current Anon CVS - this patch ensures 
that if any tests fail any files that require cleaning up are cleaned 
up. 
 
It's a minimal touch patch rather than anything else. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017550&group_id=5470
From noreply at sourceforge.net  Fri Aug 27 17:13:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 27 17:13:55 2004
Subject: [Patches] [ python-Patches-997284 ] Allow pydoc to work with XP
	Themes (.manifest file)
Message-ID: 

Patches item #997284, was opened at 2004-07-24 14:52
Message generated for change (Comment added) made by glchapman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow pydoc to work with XP Themes (.manifest file)

Initial Comment:
In Python 2.3.4, if you run pydoc -g under Windows XP
when one of the special XP theme manifest files has
been defined for python.exe or pythonw.exe, pydoc will
cause an access violation when it closes.  One solution
is obviously to get rid of the manifest files, but
wxPython installs them by default and apps written with
it work without a problem.  So it would be nice if
pydoc would also work, and it turns out it didn't take
a big change.  Attached is a patch which fixes the
problem (at least on my system).  I noticed that idle
did not have the access violation problem, and so
copied what it does in PyShell.main.

It might be better to introduce a more general fix for
Tkinter.  The problem seems to be that Uxtheme.dll
frees up some global data before all the windows have
called CloseThemeData (at app shutdown).  The AV seems
to happen when a call to CloseThemeData (presumably in
response to a WM_DESTROY message) passes a bad pointer
to RtlEnterCriticalSection.  Anyway, it seems that if
you get the window handles destroyed earlier in
shutdown, the problem is fixed.  Perhaps there is some
way to provide the Tkinter module with an atexit
handler which would destroy any existing widgets?


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2004-08-27 07:13

Message:
Logged In: YES 
user_id=86307

I'm fairly sure the problem is that Tk is calling
DestroyWindow (a User32 function) during handling of a
DLL_PROCESS_DETACH; according to the documentation of
DllMain this is unsupported and may cause access violations
(only calls to Kernel32.dll routines are safe).  The reason
for the AV is presumably that uxtheme.dll gets
DLL_PROCESS_DETACH first and frees its global data (I
believe the AV only happens if DestroyWindow is called on
windows which are, or have children which are, themed
controls).  I haven't built a debug version of the Tk dlls
since I'm not actually sure what source base is used to
produce them.  However, if they are produced from the
tktoolkit project on sourceforge, it appears
DLL_PROCESS_DETACH results in a call to TkFinalize, which
runs a set of exit handlers.  It appears one of these is
DeleteWindowsExitProc, which calls Tk_DestroyWindow on
various windows.  If various conditions are met, this will
result in a call to XDestroyWindow, which may in turn call
DestroyWindow.

Perhaps the answer is to reinstate the Py_AtExit
registration of Tcl_Finalize.  On windows, anyway, the
problem noted in the comment in _tkinter.c still exists in
Python 2.3.4.  If you give a  handler to a window
which is not destroyed by Python, it is apparently destroyed
with the DLL cleanup code, triggering a Python fatal error
for a NULL thread state (see the attached test.py, a hacked
up wsgui which I've been using for testing).  So anyway,
some other fix is needed for the  handler problem,
and it looks like Tcl_Finalize would run the Tk exit procs
before the handling of DLL_PROCESS_DETACH.



----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-23 12:03

Message:
Logged In: YES 
user_id=21627

I'd still woud prefer if a "proper" patch would be found,
i.e. one that doesn't cause a crash in response to
WM_DESTROY. For that, one would have to understand why it
crashes, and see whether it is Tk's fault - if so, Tk should
be fixed. If it really is presumed to be a Windows
bug/limitation, I'd like to see the KB article that
acknowledges the problem, and apply the work-around
suggested in the KB.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2004-08-23 05:27

Message:
Logged In: YES 
user_id=86307

I admit the cause is obscure, but I think the problem will
potentially affect most Tkinter programs (see for example,
www.python.org/sf/774188 -- which links to a wiki article
referring to crashes in Tkinter with manifest files
present).  I just tried pynche.pyw, redemo.py, wcgui.py, and
wsgui.py (from the Tools branch) and they all crashed on
exit (at the same location in kernel32, with the same
attempt to read 0x00000028).  This is with Python 2.3.4
under XP (I don't have access to an XP SP2 machine right
now: I wonder if this has been fixed).

Anyway, I added the following to Tkinter, and the crashes
went away (I don't usually use Tkinter, so this may not be
the best way to accomplish this):

import atexit

def _tkAtExit():
    if _default_root is not None:
        _default_root.destroy()

atexit.register(_tkAtExit)


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-22 08:15

Message:
Logged In: YES 
user_id=21627

This is quite an obscure problem, so I added a comment an
committed it as pydoc.py 1.86.8.3 and 1.97, NEWS 1.831.4.144.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997284&group_id=5470
From noreply at sourceforge.net  Fri Aug 27 21:00:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Aug 27 21:00:08 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: Open
Resolution: None
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-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  Sat Aug 28 14:14:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 28 14:14:31 2004
Subject: [Patches] [ python-Patches-1017550 ] Fix for bug 1017546
Message-ID: 

Patches item #1017550, was opened at 2004-08-27 14:26
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017550&group_id=5470

Category: Tests
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael (ms_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug 1017546

Initial Comment:
Attached patch is against current Anon CVS - this patch ensures 
that if any tests fail any files that require cleaning up are cleaned 
up. 
 
It's a minimal touch patch rather than anything else. 
 

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-28 14:14

Message:
Logged In: YES 
user_id=469548

Note that I've ported test_inspect to unittest a few days
ago. It's currently waiting for review at
http://python.org/sf/736962. I think it fixes bug 1017546 as
well, but it would be nice if you could take a look at it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017550&group_id=5470
From noreply at sourceforge.net  Sat Aug 28 22:05:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Aug 28 22:06:01 2004
Subject: [Patches] [ python-Patches-1018291 ] ifdeffery patch
Message-ID: 

Patches item #1018291, was opened at 2004-08-28 13:05
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=1018291&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: ifdeffery patch

Initial Comment:

when WITH_TSC is not defined, the patch defines
rdtscll() macro as no-op

#ifndef WITH_TSC 
#define rdtscll(var)
...

this allows to remove  
#ifdef WITH_TSC brackes from many places of the code

and
#ifdef WITH_TSC
    rdtscll(x);                         
#endif 

becomes simply : rdtscll(x)

(see also "#ifdeffery" thread on python-dev)





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018291&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 00:12:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 00:12:40 2004
Subject: [Patches] [ python-Patches-1018291 ] ifdeffery patch
Message-ID: 

Patches item #1018291, was opened at 2004-08-28 15:05
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018291&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
>Assigned to: Martin v. L?wis (loewis)
Summary: ifdeffery patch

Initial Comment:

when WITH_TSC is not defined, the patch defines
rdtscll() macro as no-op

#ifndef WITH_TSC 
#define rdtscll(var)
...

this allows to remove  
#ifdef WITH_TSC brackes from many places of the code

and
#ifdef WITH_TSC
    rdtscll(x);                         
#endif 

becomes simply : rdtscll(x)

(see also "#ifdeffery" thread on python-dev)





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018291&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 02:19:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 02:19:10 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 (Tracker Item Submitted) made by Item Submitter
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: Nobody/Anonymous (nobody)
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 13:15:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 13:15:31 2004
Subject: [Patches] [ python-Patches-1018509 ] fix bug 807871 :
	tkMessageBox.askyesno wrong result
Message-ID: 

Patches item #1018509, was opened at 2004-08-29 11:15
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=1018509&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018509&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 13:16:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 13:16:14 2004
Subject: [Patches] [ python-Patches-1018509 ] fix bug 807871 :
	tkMessageBox.askyesno wrong result
Message-ID: 

Patches item #1018509, was opened at 2004-08-29 11:15
Message generated for change (Settings changed) made by jiba
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: Open
Resolution: None
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018509&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 17:47:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 17:47:33 2004
Subject: [Patches] [ python-Patches-934711 ] platform-specific entropy
Message-ID: 

Patches item #934711, was opened at 2004-04-14 06:05
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 6
Submitted By: Trevor Perrin (trevp)
Assigned to: Martin v. L?wis (loewis)
Summary: platform-specific entropy

Initial Comment:

This is a very simple module for accessing platform-
specific entropy sources.  

On Win32, it uses CryptGenRandom.  Otherwise, it tries 
to use /dev/urandom.  If it can't find that, it raises 
NotImplementedError.

>>> import entropy
>>> entropy.entropy(10)
'\x99/\xbd\x8e\xb0\xfbz/\xf6\xe9'

To compile for Win32, you have to link with "advapi32".  
The /dev/urandom code has not been tested.

Issues:

 - I believe this works with all versions of Windows later 
than Win95.  But I'm not sure.

 - there's overhead in opening/closing the source.  On 
Win32 at least, opening it is slower than reading from it -
 it seems to take around 1/5th of a millisecond (i.e. I 
can make 5000 calls per second).  I think this is okay; 
you can make fewer calls and buffer the results, or seed 
your own PRNG.  However, we could make it more 
object-based, where you open an entropy-source, and 
then repeatedly read from it.

 - It would be nice if there was some attribute that told 
you what source you were using, so you could display 
it, and in case you trust /dev/urandom but not Win32's 
CryptoAPI, for example.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 17:47

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

libos.tex 1.141
os.py 1.78
test_os.py 1.26
NEWS 1.1117
posixmodule.c 2.322


----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-08-26 10:53

Message:
Logged In: YES 
user_id=973611

Hi Martin,

Thanks for looking at this.  I uploaded a new patch (5th
version) with docs, tests, and your suggestions.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-25 15:31

Message:
Logged In: YES 
user_id=21627

I also like the patch, but I think a number of changes are
still needed:
- there is no documentation
- there are no test cases
- Don't use Py_BuildValue, use PyString_FromStringAndSize
instead
- Don't stat /dev/urandom when importing os, instead, stat
on first usage, and raise NotImplementedError if no source
of randomness can be found.

As an option, support for PRNG could be added (e.g. by
checking an environment variable), but that can be left to
anybody who actually has and needs PRNG.

As for leaving the fd open: this is ok, I think, if it isn't
opened until first use.

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-05-02 04:20

Message:
Logged In: YES 
user_id=499

This version looks exactly like what I need.  I really hope
it gets accepted for 2.4.

(I have no strong opinion on whether the fd/crypto context
should be held open.)

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-27 09:21

Message:
Logged In: YES 
user_id=973611

I'm uploading a 4th version that does this as an
"os.urandom()" function.  The win32 code is in
posixmodule.c, and the /dev/urandom code is in os.py.

I think the name "urandom" is better than "entropy" - to
some people, "entropy" sounds more like /dev/random. 
"urandom" makes it clear that we're trying to provide
/dev/urandom-like functionality across platforms (i.e.: try
to use real entropy, but if you have to stretch it with a
cryptographic PRNG that's okay).

Also, I cleaned up error-handling, so it will always return
OSError (or an OSError subclass, like WindowsError).  

Finally I changed it to open the random source once, instead
of re-opening it every call.  At least on windows this is a
big speedup - from being able to make 5K calls per second it
can now make 250K.  It's probable that people will write
crypto code using this as their sole RNG source, so this is
probably worthwhile.  This introduces a small risk of
leaking file descriptors/handles if the os module is
reloaded, but I think that's okay. 

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-26 19:11

Message:
Logged In: YES 
user_id=499

Your lastest version works fine for me (on Redhat Linux 9),
but I still think it would be a better idea to write the
/dev/urandom-ish code in Python, using os.open.  That way,
you could report better error messages if /dev/urandom is
inaccessable, instead of simply claiming that it "wasn't
found."  (Maybe it was found, but we don't have permission
to access it.)

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-26 05:53

Message:
Logged In: YES 
user_id=973611


> - I can't find a statement on the page you link about using
> CRYPT_VERIFYCONTEXT that way,

Note that retrying on NTE_BAD_KEYSET is only described under
the heading  "Private Key Operations Are Performed", in
which case you need to open/create a private key container.
 But if you use CRYPT_VERIFYCONTEXT it just creates a
temporary context in memory.  More corroboration:
http://tinyurl.com/2ct2o

For awhile I was distributing code without
CRYPT_VERIFYCONTEXT, and a user ran into the NTE_BAD_KEYSET
error.  But CRYPT_VERIFYCONTEXT fixed it, which is how I
stumbled on this...

> - One more important issue: It is a bad idea to use stdio
> (C's 'fopen', Python's builtin 'open') to read from
> /dev/urandom.

Good point.  I've tried to update the code to use syscalls.
 Is there any chance you could test this out, and see
whether the #includes look correct and portable?  I don't
have a UNIX box available.  If it needs fixes, feel free to
upload a new version.

----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-26 02:49

Message:
Logged In: YES 
user_id=499

Thanks for the reply!

- As for /dev/*random -- yes, I believe you are right, and
/dev/urandom is almost always what you want.  I haven't been
able to find a platform that has one of the others, but
lacks /dev/urandom.

- I can't find a statement on the page you link about using
CRYPT_VERIFYCONTEXT that way, but you may well be right anway.

- One more important issue: It is a bad idea to use stdio
(C's 'fopen', Python's builtin 'open') to read from
/dev/urandom.  Most stdio implementation buffer data; on my
GNU/Linux box, when I call open('/dev/urandom').read(10), my
underlying fread() function sucks 4096 bytes into memory. 
(It does other weird stuff too, including calls to stat64,
mmap, and others.)  This has proved to be a problem in the
past, especially when running on systems with heavy user
process limits.  Instead, it is a better idea to use the
open syscall directly (open in C, os.open in Python).

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-26 02:08

Message:
Logged In: YES 
user_id=973611


Thanks for the comments! - 

> - According to MSDN, CryptGenRandom exists on Win98 and
> later, and on Win95 OSR2, and on Win95 with IE 3.something
> or later.

I'm uploading a new version that fails gracefully on old
Win95s (that's the only change).

> - It's necessary on some platforms, and for some
> applications, to use a device other than /dev/urandom. 
> (Some high-security code demands /dev/random; some 
> OpenBSD people swear by /dev/arandom; and so on.)

My understanding is that /dev/random should only be used in
exceptionally rare cases, if at all.  You can turn up
several posts by David Wagner, a respected cryptographer,
about this.  For example:
http://tinyurl.com/2z2fx

In any case, if you really want /dev/random, or one of the
OpenBSD variants (arandom, srandom, prandom, etc.), it's
easy to do it yourself: open("/dev/random").read().

So I think we should ignore these and stick with
/dev/urandom, since it's the easiest-to-use (non-blocking)
and most portable (unless there are systems that don't offer
it?).

> - Maybe it would be a good idea to only implement the
> windows CryptGenRandom part in C, and implement the Unix
> part in Python.

That's not a bad idea - I sorta think this function should
be placed in the 'os' module, instead of its own module.  So
we could put the /dev/urandom code in 'os.py', and allow
more specific code in, e.g., posixmodule.c to override it.  

We could also add a variable 'os.entropySource' which would
return '/dev/urandom', or 'CryptoAPI', or whatever.

> - According to the MSDN documentation for
> CryptAcquireContext, if your first call fails, you're
> supposed to retry with a final argument of 
> CRYPT_NEWKEYSET before you report an error.

I'm pretty sure using CRYPT_VERIFYCONTEXT eliminates the
need for that:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q238187&ID=KB;EN-US;Q238187








----------------------------------------------------------------------

Comment By: Nick Mathewson (nickm)
Date: 2004-04-25 20:55

Message:
Logged In: YES 
user_id=499

This patch would be tremendously valuable to me.  I've had
to maintain similar code for a couple of projects, and
having this functionality in Python would make my life one
step similar.

A few comments:
- According to MSDN, CryptGenRandom exists on Win98 and
later, and on Win95 OSR2, and on Win95 with IE 3.something
or later.

- It's necessary on some platforms, and for some
applications, to use a device other than /dev/urandom. 
(Some high-security code demands /dev/random; some OpenBSD
people swear by /dev/arandom; and so on.)

- Maybe it would be a good idea to only implement the
windows CryptGenRandom part in C, and implement the Unix
part in Python.  Then you could expose the windows code as
(say) "entopy.win_entropy(nBytes)", the unix part as (say)
"entropy.unix_entropy(nBytes, file='/dev/urandom')", and
have "entropy.entropy(nBytes)" be a cross-platform wrapper.
 This would cut down on the amount of C you need to add;
make it easier to switch entropy devices; provide better
errors when /dev/urandom is unreadable; and provide users
the option to trust only certain entropy sources.

- I believe that you're right not to worry too much about
the performance here.

- According to the MSDN documentation for
CryptAcquireContext, if your first call fails, you're
supposed to retry with a final argument of CRYPT_NEWKEYSET
before you report an error.  I don't know when/if this is
necessary, or whether there are hidden gotchas.

Once again, this patch is a great idea, and I heartily hope
that it gets in!

----------------------------------------------------------------------

Comment By: Trevor Perrin (trevp)
Date: 2004-04-14 08:19

Message:
Logged In: YES 
user_id=973611

Just a thought - this might make sense as a function within 
the 'os' module, instead of its own module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934711&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 17:52:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 17:52:21 2004
Subject: [Patches] [ python-Patches-1018291 ] ifdeffery patch
Message-ID: 

Patches item #1018291, was opened at 2004-08-28 22:05
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018291&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. L?wis (loewis)
Summary: ifdeffery patch

Initial Comment:

when WITH_TSC is not defined, the patch defines
rdtscll() macro as no-op

#ifndef WITH_TSC 
#define rdtscll(var)
...

this allows to remove  
#ifdef WITH_TSC brackes from many places of the code

and
#ifdef WITH_TSC
    rdtscll(x);                         
#endif 

becomes simply : rdtscll(x)

(see also "#ifdeffery" thread on python-dev)





----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 17:52

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as ceval.c 2.416.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018291&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 18:00:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 18:00:20 2004
Subject: [Patches] [ python-Patches-1017405 ] bsddb's DB.keys() method
	ignores transaction argument
Message-ID: 

Patches item #1017405, was opened at 2004-08-27 08:01
Message generated for change (Comment added) made by loewis
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: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
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: Martin v. L?wis (loewis)
Date: 2004-08-29 18: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  Sun Aug 29 18:01:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 18:01:49 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 02:19
Message generated for change (Comment added) made by loewis
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: Martin v. L?wis (loewis)
Date: 2004-08-29 18: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  Sun Aug 29 18:36:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 18:37:16 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-12 00:50
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 18:36

Message:
Logged In: YES 
user_id=21627

Based on Tim's approval, I have applied this patch as

libdifflib.tex 1.18
difflib.py 1.23
test_difflib.py 1.11
test_difflib_expect.html 1.1
ACKS 1.279
NEWS 1.1118
diff.py 1.4

If you want to make further changes to the code, please
submit them as diff against the current CVS, in a new SF
patch. Please generate this diff through "cvs diff -u" if
possible, as this will put the proper file path into each
chunk, so that patch does not need to ask what file each
chunk applies to.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-20 10:12

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) added optional line wrapping using a wrapcolumn argument 
to make_file and make_table methods.
2) eliminated a number of optional arguments to simplify API 
(as discussed).
3) made everything protected (by naming convention) except 
for the public make_table and make_file methods (as 
discussed).

NOTE1

I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a month or so back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

NOTE2

I will not be monitoring emails or this patch from Saturday 
Aug21 thru Wednesday Aug25.  When I break my internet 
silence I'll see if I've blundered this update (unlikely because I 
tested it pretty well but none the less possible).  If 
everything went well I will be soliciting Python-Dev to try to 
get this in alpha3.  I need someone with checkin privledges to 
do it.  Should I be trying to gather more support for its 
inclusion or does this only need to be done to convince 
someone with checkin privledges to apply the patch?

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-19 16:08

Message:
Logged In: YES 
user_id=995755

Should we expect the user to search/replace the style sheet
in the generated HTML?  I'm on a simplification kick and
this would keep the API from getting bigger.  I'm inclined
to do the same for  title and headers so I could eliminate
them from the API.

I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date.  I'm
currently testing and updating the documentation.  Hope to
post it late tonight or tommorow.

If there is anything else that should be changed, now would
be a good time to speak up!

Thanks again for everyone's help.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-19 05:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 18:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-17 04:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 19:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 18:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 17:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 15:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 07:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-06 06:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 16:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 14:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 07:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 06:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 22:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 22:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 21:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 19:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-29 00:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 00:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 23:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 21:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 19:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 18:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 17:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 16:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 16:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 08:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 15:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 17:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 06:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 22:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 18:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 18:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 17:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 17:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 15:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 15:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 13:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 15:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 21:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 11:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 11:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 08:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 20:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 20:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 08:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 16:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 06:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 15:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 18:45:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 18:48:54 2004
Subject: [Patches] [ python-Patches-973204 ] Fix for compilation with
	runtime_library_dirs
Message-ID: 

Patches item #973204, was opened at 2004-06-15 14:10
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=973204&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Antti Honkela (ahonkela)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for compilation with runtime_library_dirs

Initial Comment:
Compilation of extension modules using
runtime_library_dirs fails on HP Tru64 Unix and IRIX
because distutils tries to use linker option -R/path to
set the rpath.  The correct option on these platforms
is '-rpath /path'. The fix requires a change to
CCompiler.runtime_library_dir_option return value type
because of the need to add two separate arguments,
'-rpath' and '/path'.

According to man page of ld(1) on Tru64, the compiler
would expect a colon separated path as argument for
-rpath and only honors the last of multiple -rpath
arguments, so the module is still broken on Tru64 if
using multiple directories in runtime_library_dirs.
Fixing this would require even greater architectural
changes, so I will skip it, as I don't need it myself.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 18:45

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as

ccompiler.py 1.60
unixccompiler.py 1.56
ccompiler.py 1.57.10.1
unixccompiler.py 1.54.8.1
NEWS 1.831.4.149


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=973204&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 18:53:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 18:54:01 2004
Subject: [Patches] [ python-Patches-727483 ] AUTH_TYPE and REMOTE_USER for
	CGIHTTPServer.py:run_cgi()
Message-ID: 

Patches item #727483, was opened at 2003-04-25 16:40
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727483&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Oleg Broytmann (phd)
Assigned to: Nobody/Anonymous (nobody)
Summary: AUTH_TYPE and REMOTE_USER for CGIHTTPServer.py:run_cgi()

Initial Comment:
The patch adds env['AUTH_TYPE'] and env['REMOTE_USER']
for CGIHTTPServer.py:run_cgi(), if there was
Authorization header and if the header can be parsed
according to WWW-Authorization rules. REMOTE_USER
actually extracted from the header only if the header
shows it is Basic Authorization.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 18:53

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Applied as CGIHTTPServer 1.36

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=727483&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 18:56:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 18:56:26 2004
Subject: [Patches] [ python-Patches-723940 ] Backport of recent sre fixes.
Message-ID: 

Patches item #723940, was opened at 2003-04-19 01:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Backport of recent sre fixes.

Initial Comment:
This patch should reproduce, in the release22-maint 
branch, an exact copy of the sre code currently in the 2.3 
branch, with the single exception of the  declaration of the 
module init function.  All future patches should apply 
cleanly to both 2.3 and 2.2 branches. 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 18:56

Message:
Logged In: YES 
user_id=21627

2.2 is no longer maintained, so I'm rejecting this patch.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-21 08:57

Message:
Logged In: YES 
user_id=21627

I would be careful with copying changes. In particular, they
should not be copied if they are not fully understood. sre
is a very delicate library: difficult to understand, easy to
break, and, if broken, causing harm to many users.

Therefore, I think a strict "bug fixes only" policy should
be applied when backporting SRE fixes. Unless there is
demonstrated breakage that get fixed by applying a patch, no
backport of the patch should be made. 

By this criterion, my changes to use BIGCHARSET in UCS-4
mode should not be backported, as they don't fix a
correctness bug (they do improve performance, but at the
cost of changing the SRE bytecode interface)

----------------------------------------------------------------------

Comment By: Gary Herron (herron)
Date: 2003-04-21 03:55

Message:
Logged In: YES 
user_id=395736

Gustavo, 
 
If I understand correctly: 
 
* The backport to 2.2 done by just copying the code from 2.3 is 
not the problem, but merely needs to be repeated in light of 
changes made, by you and Martin, to 2.3 in that last several 
days. 
   
* The "Greg Chapman's patch" you refer to in the checkin 
comment of revision of 2.91 of _sre.c is from before I came 
on-board, and is not the MIN_REPEAT_ONE stuff I got from him 
and gave to Guido to produce revision 2.88. 
 
* That previous patch of Greg's (revision 2.84 of _sre.c) caused 
some bugs (or at least discrepancies) which you have now 
resolved in the last day or two. 
 
* The MIN_REPEAT_ONE stuff of Greg's is not at issue. 
 
* The LASTMARK_SAVE()/LASTMARK_RESTORE() calls were 
added (quite recently) to fix some bugs, and perhaps are needed 
in other spots if we were to be clever enough (or unlucky 
enough) to provoke them. 
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-21 00:00

Message:
Logged In: YES 
user_id=21627

Why does the patch remove partial history?

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-04-20 23:59

Message:
Logged In: YES 
user_id=7887

No problems. I'll check the patch and workout any issues
with Gary.

Thanks for pointing me this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-20 22:09

Message:
Logged In: YES 
user_id=6380

Assigning this to Gustavo Niemeyer, who found some problems
with this code in 2.3. Gustavo, would you mind working with
Gary on backporting this properly?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723940&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 21:40:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 21:40:35 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-29 15:40

Message:
Logged In: YES 
user_id=31435

Dan, there's a problem you need to fix:  all .py files in the 
core are run thru reindent.py, which, among other things, 
chops invisible trailing whitespace off lines.  Some of your 
new lines in difflib.py and in test_difflib.py do have invisible 
trailing whitespace (especially inside triple-quote strings), and 
test_difflib fails when that junk is removed.

Repairing this is probably just a matter of running reindent.py 
on those files, then generating a new 
test_difflib_expect.html.  Please verify that's all that's 
needed.  If you say it is, I'll do that and check in the result.  
Else we'll have to revert the checkin.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 12:36

Message:
Logged In: YES 
user_id=21627

Based on Tim's approval, I have applied this patch as

libdifflib.tex 1.18
difflib.py 1.23
test_difflib.py 1.11
test_difflib_expect.html 1.1
ACKS 1.279
NEWS 1.1118
diff.py 1.4

If you want to make further changes to the code, please
submit them as diff against the current CVS, in a new SF
patch. Please generate this diff through "cvs diff -u" if
possible, as this will put the proper file path into each
chunk, so that patch does not need to ask what file each
chunk applies to.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-20 04:12

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) added optional line wrapping using a wrapcolumn argument 
to make_file and make_table methods.
2) eliminated a number of optional arguments to simplify API 
(as discussed).
3) made everything protected (by naming convention) except 
for the public make_table and make_file methods (as 
discussed).

NOTE1

I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a month or so back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

NOTE2

I will not be monitoring emails or this patch from Saturday 
Aug21 thru Wednesday Aug25.  When I break my internet 
silence I'll see if I've blundered this update (unlikely because I 
tested it pretty well but none the less possible).  If 
everything went well I will be soliciting Python-Dev to try to 
get this in alpha3.  I need someone with checkin privledges to 
do it.  Should I be trying to gather more support for its 
inclusion or does this only need to be done to convince 
someone with checkin privledges to apply the patch?

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-19 10:08

Message:
Logged In: YES 
user_id=995755

Should we expect the user to search/replace the style sheet
in the generated HTML?  I'm on a simplification kick and
this would keep the API from getting bigger.  I'm inclined
to do the same for  title and headers so I could eliminate
them from the API.

I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date.  I'm
currently testing and updating the documentation.  Hope to
post it late tonight or tommorow.

If there is anything else that should be changed, now would
be a good time to speak up!

Thanks again for everyone's help.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-18 23:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 12:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 22:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 13:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 12:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 11:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 09:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 01:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-06 00:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 10:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 08:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 01:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 00:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 16:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 15:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 18:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 18:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Sun Aug 29 23:20:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Aug 29 23:20:34 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 17:50
Message generated for change (Comment added) made by dmgass
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Dan Gass (dmgass)
Date: 2004-08-29 16:20

Message:
Logged In: YES 
user_id=995755

Tim, sorry for the inconvenience.  I ran reindent.py over
all the .py files and duplicated what you saw --
test_difflib.py does fail due to white space being removed
from triple-quoted template strings. 

You are correct, the proper action is to run reindent.py
over the .py files and regenerate test_difflib_expect.html.
 (It can be done by temporarily uncommenting three lines in
test_difflib.py on the lines following "# temporarily
uncomment".)  I went through this exercise and verified the
new expectations are OK.  (After regenerating, you may want
to open test_difflib_expect.html just to make sure it
renders reasonably for a sanity check.)  

I would volunteer to generate a new patch file but I do not
have direct access to the CVS archives and this would
probably create as much work for you as I save.  I
appreciate your offer to help.  If there is anything else I
should do let me know by posting here or emailing me
directly at dan.gass at gmail.com.

Thanks,
Dan

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-29 14:40

Message:
Logged In: YES 
user_id=31435

Dan, there's a problem you need to fix:  all .py files in the 
core are run thru reindent.py, which, among other things, 
chops invisible trailing whitespace off lines.  Some of your 
new lines in difflib.py and in test_difflib.py do have invisible 
trailing whitespace (especially inside triple-quote strings), and 
test_difflib fails when that junk is removed.

Repairing this is probably just a matter of running reindent.py 
on those files, then generating a new 
test_difflib_expect.html.  Please verify that's all that's 
needed.  If you say it is, I'll do that and check in the result.  
Else we'll have to revert the checkin.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 11:36

Message:
Logged In: YES 
user_id=21627

Based on Tim's approval, I have applied this patch as

libdifflib.tex 1.18
difflib.py 1.23
test_difflib.py 1.11
test_difflib_expect.html 1.1
ACKS 1.279
NEWS 1.1118
diff.py 1.4

If you want to make further changes to the code, please
submit them as diff against the current CVS, in a new SF
patch. Please generate this diff through "cvs diff -u" if
possible, as this will put the proper file path into each
chunk, so that patch does not need to ask what file each
chunk applies to.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-20 03:12

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) added optional line wrapping using a wrapcolumn argument 
to make_file and make_table methods.
2) eliminated a number of optional arguments to simplify API 
(as discussed).
3) made everything protected (by naming convention) except 
for the public make_table and make_file methods (as 
discussed).

NOTE1

I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a month or so back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

NOTE2

I will not be monitoring emails or this patch from Saturday 
Aug21 thru Wednesday Aug25.  When I break my internet 
silence I'll see if I've blundered this update (unlikely because I 
tested it pretty well but none the less possible).  If 
everything went well I will be soliciting Python-Dev to try to 
get this in alpha3.  I need someone with checkin privledges to 
do it.  Should I be trying to gather more support for its 
inclusion or does this only need to be done to convince 
someone with checkin privledges to apply the patch?

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-19 09:08

Message:
Logged In: YES 
user_id=995755

Should we expect the user to search/replace the style sheet
in the generated HTML?  I'm on a simplification kick and
this would keep the API from getting bigger.  I'm inclined
to do the same for  title and headers so I could eliminate
them from the API.

I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date.  I'm
currently testing and updating the documentation.  Hope to
post it late tonight or tommorow.

If there is anything else that should be changed, now would
be a good time to speak up!

Thanks again for everyone's help.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-18 22:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 11:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 21:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 12:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 11:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 10:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 08:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 00:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-05 23:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 09:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 07:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 00:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-03 23:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 15:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 15:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 14:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 12:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 09:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 17:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 16:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 14:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 12:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 11:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 09:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 09:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 01:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 08:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 01:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 10:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-23 23:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 15:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 11:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 10:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 10:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 08:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 08:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 06:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 08:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 14:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 04:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 01:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 13:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 13:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 01:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 09:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-28 23:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 08:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 00:21:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 00:21:15 2004
Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation
Message-ID: 

Patches item #936813, was opened at 2004-04-17 04: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=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: Tim Peters (tim_one)
Date: 2004-08-29 18: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 04: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 15: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 07: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 23: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 04: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 Aug 30 00:40:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 00:41:18 2004
Subject: [Patches] [ python-Patches-914575 ] difflib side by side diff
	support, diff.py s/b/s HTML option
Message-ID: 

Patches item #914575, was opened at 2004-03-11 18:50
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470

Category: Modules
Group: Python 2.4
Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Dan Gass (dmgass)
Assigned to: Nobody/Anonymous (nobody)
Summary: difflib side by side diff support, diff.py s/b/s HTML option

Initial Comment:
lib/difflib.py:

Added support for generating side by side differences.  
Intended to be used for generating HTML pages but is 
generic where it can be used for other types of markup.

tools/scripts/diff.py:

Added -m option to use above patch to generate an 
HTML page of side by side differences between two 
files.  The existing -c option when used with the new -m 
option controls whether contextual differences are 
shown or whether the entire file is displayed (number of 
context lines is controlled by existing -l option).

NOTES:
(1) Textual context diffs were included as requested.  In 
addition, full and contextual HTML side by side 
differences (that this patch generated) are also included 
to assist in analyzing the differences and showing an 
example.

(2) If this functionality is worthy of inclusion in the 
standard python distribution, I am willing to provide more 
documentation or make modifications to change the 
interface or make improvements.

(3) When using Internet Explorer some font sizes seem 
to skew things a bit.  Generally I've found the "smallest" 
to work best.  If someone knows why, I'd be interested 
in making any necessary adjustments in the generated 
HTML.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-08-29 18:40

Message:
Logged In: YES 
user_id=31435

Thanks, Dan!  I checked the changes in.  The new HTML file 
wasn't obviously damaged, but since I'm not intimately 
familiar with what it's intending to show, I could well be 
missing something.  If it looked OK to you when you tried it, 
I'm not gonna argue .  Looks good!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-29 17:20

Message:
Logged In: YES 
user_id=995755

Tim, sorry for the inconvenience.  I ran reindent.py over
all the .py files and duplicated what you saw --
test_difflib.py does fail due to white space being removed
from triple-quoted template strings. 

You are correct, the proper action is to run reindent.py
over the .py files and regenerate test_difflib_expect.html.
 (It can be done by temporarily uncommenting three lines in
test_difflib.py on the lines following "# temporarily
uncomment".)  I went through this exercise and verified the
new expectations are OK.  (After regenerating, you may want
to open test_difflib_expect.html just to make sure it
renders reasonably for a sanity check.)  

I would volunteer to generate a new patch file but I do not
have direct access to the CVS archives and this would
probably create as much work for you as I save.  I
appreciate your offer to help.  If there is anything else I
should do let me know by posting here or emailing me
directly at dan.gass at gmail.com.

Thanks,
Dan

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-29 15:40

Message:
Logged In: YES 
user_id=31435

Dan, there's a problem you need to fix:  all .py files in the 
core are run thru reindent.py, which, among other things, 
chops invisible trailing whitespace off lines.  Some of your 
new lines in difflib.py and in test_difflib.py do have invisible 
trailing whitespace (especially inside triple-quote strings), and 
test_difflib fails when that junk is removed.

Repairing this is probably just a matter of running reindent.py 
on those files, then generating a new 
test_difflib_expect.html.  Please verify that's all that's 
needed.  If you say it is, I'll do that and check in the result.  
Else we'll have to revert the checkin.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-29 12:36

Message:
Logged In: YES 
user_id=21627

Based on Tim's approval, I have applied this patch as

libdifflib.tex 1.18
difflib.py 1.23
test_difflib.py 1.11
test_difflib_expect.html 1.1
ACKS 1.279
NEWS 1.1118
diff.py 1.4

If you want to make further changes to the code, please
submit them as diff against the current CVS, in a new SF
patch. Please generate this diff through "cvs diff -u" if
possible, as this will put the proper file path into each
chunk, so that patch does not need to ask what file each
chunk applies to.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-20 04:12

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) added optional line wrapping using a wrapcolumn argument 
to make_file and make_table methods.
2) eliminated a number of optional arguments to simplify API 
(as discussed).
3) made everything protected (by naming convention) except 
for the public make_table and make_file methods (as 
discussed).

NOTE1

I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a month or so back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

NOTE2

I will not be monitoring emails or this patch from Saturday 
Aug21 thru Wednesday Aug25.  When I break my internet 
silence I'll see if I've blundered this update (unlikely because I 
tested it pretty well but none the less possible).  If 
everything went well I will be soliciting Python-Dev to try to 
get this in alpha3.  I need someone with checkin privledges to 
do it.  Should I be trying to gather more support for its 
inclusion or does this only need to be done to convince 
someone with checkin privledges to apply the patch?

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-19 10:08

Message:
Logged In: YES 
user_id=995755

Should we expect the user to search/replace the style sheet
in the generated HTML?  I'm on a simplification kick and
this would keep the API from getting bigger.  I'm inclined
to do the same for  title and headers so I could eliminate
them from the API.

I have completed the line wrapping functionality and the
simplifications/streamlining talked about to date.  I'm
currently testing and updating the documentation.  Hope to
post it late tonight or tommorow.

If there is anything else that should be changed, now would
be a good time to speak up!

Thanks again for everyone's help.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-18 23:30

Message:
Logged In: YES 
user_id=357491

Don't have to look this up to see if this is already supported, but the only 
thing that I could see people wanting is a way in inject their own 
stylesheet.  Otherwise it sounds good to me.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-17 12:58

Message:
Logged In: YES 
user_id=995755

I'm still in the process of implementing the line wrapping
and am gaining a greater appreciation for minimizing the API
(in this process I have been simplifying some of the code).
 Based on this and the feedback so far I am proposing the
following API simplifications:

class HtmlDiff():

I will be making everything protected by convention (adding
a leading underscore) except for the make_file() and
make_table() methods.  This should warn those looking at the
internals that things may change in future releases.  We may
want to consider making additional public interfaces in the
future when more experience is gained.

HtmlDiff.__init__():

1) remove 'smarttabs' argument (I will always expand tabs
using expand_tabs() string method).

HtmlDiff.make_file():
HtmlDiff.make_table():

1) remove 'fromprefix' and 'toprefix' arguments (vast
majority of applications don't need this, for now corner
cases can solve it with a string search/replace algorithm
after the fact).

2) remove 'summary' argument (this added a summary attribute
to the  tag and I believe would not be used much if
at all).  A user could always do a string search and replace
on the 
 tag to insert this after the fact.

HtmlDiff.make_file():

1) leave 'title' and 'header' arguments alone (I could be
talked into removing these).  These arguments are for
controlling the window title and any markup to be inserted
just above the table.  Although these could be inserted
after the fact using string search and replace methods I
think these will be commonly used and should be convenient
(plus they are easy to understand).

ANY OTHER API SIMPLIFICATION IDEAS?


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-16 22:25

Message:
Logged In: YES 
user_id=357491

+1 on minimizing the API as well.  Easier to expose more of an API later 
than to retract any part of it.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-16 13:04

Message:
Logged In: YES 
user_id=80475

+1 on exposing as little of the API as possible.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-16 12:53

Message:
Logged In: YES 
user_id=995755

I'm pretty far implementing the (optional) line wrapping
feature, I'll post it in the next day or two.

Assuming this goes into the next alpha, does anyone have any
objections to changing everything (except some of the
templates) to be protected (via naming everything with a
leading underscore) for this release?  It would discourage
anyone from counting on any of the internal workings so we
would be at liberty to change it in future releases should
anything shake out from its more widespread use.  I think
the templates and the API allow enough control to tailor the
output without exposing the remainder of the implementation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-13 11:36

Message:
Logged In: YES 
user_id=764593

(1)  I don't have checkin privs, so I can't help there.
(2)  Line wrapping is tricky - I couldn't think of a good way 
to do it, which is why I didn't mention it earlier.  Your way 
sounds as good as any, so long as it is easily overridden 
(including a "no wrap" option)

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-13 09:49

Message:
Logged In: YES 
user_id=995755

Quick poll to interested parties: Do you want me to add
logic to handle line wrapping now, later, or never?  Its
been something I wanted to address and I thought of a
relatively easy way to do it this morning while in the
shower.  In the code that inserts the XHTML markup I would
put temporary markers (perhaps \0,\1) around the markup so
that I could easily count visible characters accurately and
perform the break.   I'd add a "wrapcolumn" attribute to the
__init__ method that would default to None (no wrapping).  I
would break on the exact column number (not worrying about
breaking on whitespace).  I'll also put some type of
continuation marker in the line number column (probably a
single ">").

I did get a hold of Raymond.  He suggests recruiting either
Tim or another developer to work on inserting the patch as
his time is tight right now.  I'll put out a plea for help
on Python-Dev this weekend (I'll wait until after I
implement line wrapping if feedback is positive) unless I'm
lucky and get a volunteer based on this posting.

Raymond recommended a "tex" checker script that comes in the
standard distribution to run on my modifications to the .tex
documentation file.  My changes are OK.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-10 01:00

Message:
Logged In: YES 
user_id=995755

Raymond -- I am new to the Python-Dev community so I can 
only assume you would be the one to apply this patch and 
check it into CVS since this patch is assigned to you.  
Because of that and the fact that you have looked it over to 
some degree I would like to hear your opinion on when you 
think this should get it.  It would be helpful to know if it is 
going in 2.4 and what work needs to be done on my part.  I 
would rather do the work sooner than later for everyone's 
comfort level.  It may be a good break from reading about 
@|decorators :-)

I have found documentation on how to generate the HTML 
documentation from the .tex file I patched in order to check 
my work more accurately.  My suspicion is that Linux is the 
platform that would be easiest to build the documentation 
since it would already have most of the tools (I have a Suse 
Linux system at home but am not very familiar with it).  
Windows is still the most convenient platform for me to work 
under right now.  Unfortunately I do not yet have broadband 
(or internet) on my Linux home system only dial up on my 
home Windows system :-(  and high speed on my Windows 
system at work.  Any suggestions on which platform to use 
and the easiest way to obtain all the source files to get 
started would be appreciated -- I can be reached directly at 
dan.gass_at_gmail_dot_com.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-06 00:45

Message:
Logged In: YES 
user_id=995755

I did a rough performance measurement where I addressed a 
concern I had in a previous comment (function call in a list 
comprehension).  The time difference was so small I could not 
determine which was better.  Until I hear complaints about its 
speed I am not planning on looking into performance 
improvements.

As far as the "smarttab" option, I have not gotten any 
feedback.  I'm inclined to leave it as is because it allows the 
most flexibility.

I will not be monitoring this patch (or my email) from now until 
next Monday (August 9).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-04 10:00

Message:
Logged In: YES 
user_id=995755

FWIW here is some background that may help determine your
comfort level:

The basis of this code was written late last year.  Just
before submitting it as a patch early this year I cleaned it
up quite a bit.  Since that time its "core" _mdiff() has
been extremely stable.  I (we) have been using it a fair
amount where I work without problems (early on its use
flushed out some additional requirements).  Obviously I've
been using it quite a bit in this patch to show what I'm
changing.

All of the changes to date have been to 1) improve the API
to make it really easy to use yet still flexible to
customize 2) change the output to meet  XHTML 1.0
Transitional standards and 3) improve output HTML
functionality and 4) correct some corner case bugs.

Jim's notes are correct, 1) this patch is strictly an
addition to difflib.py as it required no changes to the
existing code and 2)
I am currently only involved in this patch and my config-py
sourceforge project so providing support has not and will
not be a problem.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-04 08:59

Message:
Logged In: YES 
user_id=764593

Martin -- there have been a fair number of changes, and I 
agree that major new functionality is often asked to cook for a 
release outside the core.

That said, the changes were mostly the sort of things that 
could be done even after it was in the core; they're just being 
done early.  So I'm inclined to agree with Tim in this particular 
case.  

I feel even more strongly that if it doesn't go in 2.4, then it 
should at least be targeted for 2.5, rather than an indefinate 
"future".

Also note that 

(1)  This doesn't require much in the way of changes to the 
previous code; it could be backed out if there are problems 
during the testing phase.

(2)  there are a few alphas left, plus betas, and the author 
has been very fast with fixes; if there are problems, I'm 
confident that he can fix them in plenty of time.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-08-04 01:08

Message:
Logged In: YES 
user_id=31435

The first version I saw from Dan worked fine for my tastes, 
and he's been very responsive to the unusually large number 
of suggestions made by the unusually large number of 
reviewers.  The number of reviewers demonstrates real 
interest, and while all have their own UI and API agendas to 
push, I don't see anyone opposed to the patch.  This should 
go in.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-08-04 00:41

Message:
Logged In: YES 
user_id=21627

Given that this code was developed from scratch in this
tracker, and given the loads of changes it has seen, I'd be
in favour of postponing it after 2.4.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-08-03 16:37

Message:
Logged In: YES 
user_id=995755

Is this patch being considered for going into Python 2.4
(and hence being checked into an alpha release)?  FWIW, Tim
Peters was +1 in favor of having this functionality in
Python (even before the API was significantly enhanced)
before washing his hands of it.  

I'd be interested in knowing whether this is going into 2.4,
being shelved until the next release or whether the
development/distribution of this functionlity should be
moved to its own project.  I'm getting a little anxious
because I know an alpha release is in the works this week
but I don't know how many more opportunities we have beyond
that for 2.4.  (I'm assuming there will be a long time
before the next one.)

Are there any more outstanding issues with it that need to
be resolved?  I am currently under the assumption no one has
any objections or further recommendations.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 16:10

Message:
Logged In: YES 
user_id=995755

> Rather than spending time on performance measurement, it is
> best to focus on other goals.  Aim for the smallest amount
> of code, the neatest output, greatest ease of use, and the
> simplest way to change the output appearance.

Noted.

> The size of the docs is one metric of ease of use.  Ideally,
> it would  take a paragraph or two to explain.

So far I've patched the libdifflib.tex file with about that
amount of material.  It details the "out-of-box" methods for
generating HTML side by side differences.  It does not
address templates that we are leaving public to adjust the
output.  Should the documentation be left simple with just a
reference to the doc string documentation within the module
for further information about using the templates to adjust
the output? 

> Also, write some sample code that produces a different
> output appearance (XML for example).  How easy was it to 
> do.

The _mdiff() function could be used by those interested in
doing side by side diffs with other markup such as XML. 
Previously you had mentioned that we should hide this
function for now so we can reserve the right to change the
interface.  Truthfully I did not mind this decision because
I don't think there is much need for it and it does avoid
alot of documentation work to explain how to use it :-)  

> The goal is to focus the code into three parts:  the
> underlying ndiff, converting ndiff to side-by-side, and
> output formatting.

1) ndiff() is what it is and I had no need to change it.

2) converting ndiff() to side-by-side is handled (and
packaged neatly) by _mdiff().  The code in my opinion is
well written and well commented.  It is not public code so
documentation for the python manuals is not required.

3) There has been a great deal of discussion regarding
output formatting (early on a fair amount of it was done
through private emails, but as of late everything is being
logged here).  IMHO I think the interface has shaped up very
well, but I am still open for more suggestions.  To date
most of the feedback I have gotten is on the API and the
output.  I haven't heard much about the code.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-29 15:37

Message:
Logged In: YES 
user_id=80475

Rather than spending time on performance measurement, it is
best to focus on other goals.  Aim for the smallest amount
of code, the neatest output, greatest ease of use, and the
simplest way to change the output appearance.

The size of the docs is one metric of ease of use.  Ideally,
it would  take a paragraph or two to explain.

Also, write some sample code that produces a different
output appearance (XML for example).  How easy was it to do.

The goal is to focus the code into three parts:  the
underlying ndiff, converting ndiff to side-by-side, and
output formatting.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 13:13

Message:
Logged In: YES 
user_id=995755

I think we are getting very close to having something for
the next alpha release for Python 2.4.

One exception is the last patch update I used a list
comprehension that calls a function for every line of text.
 I'm thinking I should have called the function with the
list and have it pass back a newly constructed list.  To be
sure which is the better way I want to do a performance
measurement.

I also would like to measure performance with and without
"smarttabs".  If it does not cost much I might be in favor
of eliminating the option and just doing "smarttabs" all the
time.  In addition to performance degredation it would
eliminate the ability to doing straight tab for spaces
substitution (is this bad?).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-29 10:32

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) Now handles expanding tabs and representing them with an
appropriate HTML representation.
2) moved default prefix to class-level

NOTES

N1) See _libdifflib_tex_UPDATE.html and
test_difflib_expect.html for an example of how tab
differences get rendered.

N2) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 18:41

Message:
Logged In: YES 
user_id=764593

If you're dealing with tabs anywhere except at the start of a 
line, then you probably can't solve it in a general way -- 
tabstops become variable.

If you're willing to settle for fixed-width tabstops (as on old 
typewriters, still works in some environments, works fine in 
tab-initial strings) then

tab="        "

Does everything you want in a single variable for tab-initial, 
and has all the information you need for fancy tab-internal 
processing (which I don't recommend).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 18:02

Message:
Logged In: YES 
user_id=995755

For the case where you instantiate HtmlDiff saying you want
tabs expanded it will insert non-breaking space(s) up to the
next tab stop.  

For the case where you do NOT specify tab expansion it will
substitute one non-breakable space unless you override it
with a different string (where you could choose 3,4, or 8
spaces).  We could make 3,4, or 8 spaces the default but it
makes it more complex because it would require two
overridable class-level members ...
    spaces_per_tab = 8
    tab_space = ' '
... and the post processing would look like ...
     return s.replace('\t',self.tab_space*self.spaces_per_tab)
... and the pre-processing setup in the constructor would
need to override the class-level member used for the post
processing:
     self.spaces_per_tab=1

We could also use a special character for tabs.  We could
even attempt to use a combination of nbsp and a special
character to show the tab stops.  I'd need to play with re's
to do that.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-28 17:36

Message:
Logged In: YES 
user_id=764593

Are you saying that the default will replace tabs with a single 
non-breaking space?  Not 3-4, as in many programming 
environments, or 8 as in standard keyboard, but 1?

No objections other than that.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-28 15:39

Message:
Logged In: YES 
user_id=995755

Unless I hear opposing arguments I will be updating the
patch to handle tabs and to change the default prefix to be
class-level either tonight or tommorow night. 

I plan on adding both pre and post processing to handle tabs.

Preprocessing will be controlled by an an optional keyword
argument in the HtmlDiff constructor specifying the number
of spaces per tab stop.  If absent or None is passed, no
preprocessing will occur.  Otherwise the tabs in each line
of text will be expanded to the specified tab stop spacing
(note, I will use the expandtabs() string method but will
convert the resulting expanded spaces back into tabs so they
get handled by post processing).

Post processing will always occur.  Any tabs remaining in
the HTML markup will be substituted with the contents of a
class-level variable (which can be overridden).  By default,
this variable will be set to ' '

These two changes will allow tab expansion to the correct
tab stop without sacrificing the ability to see differences
in files where tabs were converted to spaces or vice versa.
 It also provides a mechanism where by default, tabs are
reasonably represented (or can be easily changed to your
custom representation).


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 13:25

Message:
Logged In: YES 
user_id=995755

You can replace tabs with markup by overriding
format_line().  The disadvantage is that doing smart
replacements (such as expandtabs() does) is more difficult
because there could already be markup in there which doesn't
count toward the tab stops.  You can accomplish Walter's
substition easily by overriding format_line().  This
substitution cannot be done at the front end because the
markup will be escaped and displayed.  I'm seeing this as a
supporting argument for making the tab filtering optional on
the front end (dependent on how much of a performance hit it
is to do it all the time).

I intend on making the default prefix class-level so that
different HtmlDiff instances share (and increment) the same
value to avoid anchor name conflicts between two tables
placed on the same HTML page.  Jim, does that help clarify?




----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-27 12:28

Message:
Logged In: YES 
user_id=89016

Formatting one line for output should be the job of an 
overwrittable method. This makes it possible to implement 
various tab replacement schemes and possibly even syntax 
highlighting. (BTW, I'd like my tabs to be replaced by ·  )

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:12

Message:
Logged In: YES 
user_id=764593

Your tab solution sounds as good as any.

I'm not sure I understand your intent with the default context.

module-level is shared.
class-level is shared unless/until assigned.
instance-level (including "set by constructor") lets different 
HtmlDiff have different values.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-27 10:49

Message:
Logged In: YES 
user_id=995755

I am considering making an optional argument to the
constructor for specifying tab indentation.  If nothing was
passed it defaults to not handling tabs (better
performance).  If a number is passed, the string sequences
(lists of lines) would be wrapped with a generator function
to convert the tabs in each line with the expandtabs string
method.  The other option is to expand tabs all the time. 
If one is going to handle tabs it must be done on the input
because once it is processed (markup added) the algorithm
for expanding tabs becomes really compilicated.  Any
opinions regarding these options are welcome.

I think I should change the default prefix (_default_prefix)
to be a class member rather than initialize it with the
constructor.  (The default prefix is used to generate unique
anchor names so there are no conflicts between multiple
tables on the same HTML page).  I'm leaning this way because
a user may create separate instances of HtmlDiff (to have
different ndiff or tab settings) but   place the tables on
the same page.  If I left it the hyperlinks in the second
table would jump to the first table.



----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 10:11

Message:
Logged In: YES 
user_id=764593

Technically, HTML treats all whitespace (space, tab, newline, 
carriage return, etc) as interchangable with a single space, 
except sometimes when you are in a 
 block.

In practice, user agents often honor it anyhow.  If tab isn't 
working, you might have better luck replacing it with a series 
of 8  , ((ampersand, then "nbsp", then semicolon)*8) but 
I'm not sure the ugliness is worth it.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-26 02:34

Message:
Logged In: YES 
user_id=995755

Updated the patch as follows:

1) handles no differences now in both full and context mode 
(Adam discovered that it crashed when no differences in 
context mode).
2) handles empty string lists (I'm pretty sure it would have 
crashed had someone tried it).
3) "links" column in the middle now appears on the left as well.
4) Moved prefix argument from constructor to make_file and 
make_table methods.  Also made it work by default so that if 
you are generating multiple tables and putting them on the 
same HTML page there are no anchor name conflicts.
5) mdiff() function now is protected: _mdiff() so we are at 
liberty to change the interface in the future
6) templates moved to protected global variables (still public 
members of the class) so that the indenting could be 
improved.
7) Improved the indenting in other areas so that the HTML is 
now much more readable.
8) Inlined the special character escaping so that the xml.sax 
library function is not used (this seems to have improved the 
performance quite a bit).
9) Moved as many 
 attributes as possible to a style 
sheet class.  Adam, please review this incase I missed some.
10) Expanded test suite to cover the above changes and 
made it easier to baseline.
11) Updated documentation to reflect above changes.

NOTES

N1) Raymond, you had mentioned this crashes when the 
newlines are stripped.  I modified the test to include stripping 
and not and have found both to work without having to fix 
anything.  Can you duplicate what you saw and give me more 
info?

N2) I've noticed the HTML does not render tabs very well (at 
all).  Is this OK or does anyone have any good ideas?

N3) I've attached the patch (you will also need the new file 
test_difflib_expect.html).   I've zipped the patched code as 
well as example side by side differences of the patch.  Diffs 
ending with _UPDATE.html show differences between the 
patched code and the last version of the patched code (what 
I've done since my last posting).  Diffs ending with 
_PATCH.html show differences between the patched code 
and what I obtained from CVS a couple weeks back:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-25 09:51

Message:
Logged In: YES 
user_id=995755

Adam's suggestion seems to make alot of sense regarding 
moving the table attributes to a class.  I will implement it in 
the next update.  I will experiment with the font issue but will 
likely hold off on implementing anything.

Adam -- thanks for the quick feedback.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-25 02:51

Message:
Logged In: YES 
user_id=57486

> Why move the attributes to a class for the two tables?
In general its good practice to separate the style info from
the html. For this case in particular i had to do this
because i'm embedding the diff tables in a generic page
template that applies general style rules to tables in the
page. By adding a class for those tables i was able to add a
rule for it that overrode the more general table rule.

> Can I get a recommended solution for the font issue?
Not sure, I added this rule:
.diff_table th, .diff_table td
     { font-size: smaller; }  
But its a bit problematic as Mozilla defaults to a
considerably smaller monotype font size than IE so its hard
to be consistent across browsers.


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-24 11:29

Message:
Logged In: YES 
user_id=995755

I will be implementing the following suggestions:

Raymond 7/19 & 7/23 [all]
Adam 7/17 [all]
Adam 7/23 [partial, but I need feedback]
   - Can I get a recommended solution for the font issue?
   - I'll likely do the additional links column on the left
   - Why move the attributes to a class for the two tables?

Unless the template issue (public/protected/private) is 
discussed further, I will assume everyone is in agreement or 
can live with Raymond's suggestion & clarification.

I will not be implementing any changes to the API right now.  
I lean somewhat strong toward leaving the optional 
arguments as they are but this can be talked about further if 
anyone thinks there are strong arguments to the contrary.

Thanks Raymond, Adam, Jim, and Neal for your latest 
comments.  Unless I get further suggestions, expect the 
patch hopefully by the end of the weekend.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 00:20

Message:
Logged In: YES 
user_id=80475

To clarify, the private variables are just a way to move the
defaults  out of the class definition and give the OP more
control over formatting:

_legend = """


    
  Legends  

    
  

                  
 Colors  

                  
 Added 

                  
Changed 

                  
Deleted 

              

          

                  
 Links  

                  
(f)irst change 

                  
(n)ext change 

                  
(t)op 

              
 



"""

class HtmlDiff(object):

    file_template = _file_template
    styles = _styles
    linenum_template = _linenum_template
    table_template = _table_template
    legend = _legend

    def __init__(self,prefix=['from','to'], linejunk=None,
      .  .  .


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-23 16:01

Message:
Logged In: YES 
user_id=57486

certainly you need to be able to access the templates and
modify them. And should be documented too -- one of the
first things i wanted to know is how can i customize the
output. But a config object seems like conceptual clutter.
keyword arguments can be ignored and are just as persistent
if you use ** on a dict. 

few more suggestions:
* the default font seems too large on both ie 6 and firefox
(this is with 1200 x 800 screen resolution, so it'd be even
larger at a lower resolution).
* maybe the links column (t, f, n) should also be on the
left -- often there are long lines and you need to scroll
over to access it.
* add class attributes to the two tables used in the
templates and move their styles to there (except i believe
that IE doesn't honor cellpadding/spacing styles in css)

thanks

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 12:31

Message:
Logged In: YES 
user_id=764593

Actually, I'm not convinced that the templates should be 
private, though I can certainly see protected.  (double-
underscore private is mangled; single-underscore protected will 
be left out of some imports and doco, but acts like a regular 
variable if people choose to use it anyway.)

I'm still thinking about nnorwitz's suggestion; the config option 
could be ignored by most people ("use the defaults") but would 
hold persistent state for people with explicit preferences (since 
they'll probably want to make the same changes to all 
compares).


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-23 12:10

Message:
Logged In: YES 
user_id=33168

I have not reviewed the code yet, so this is just a general
comment.  I don't know if it is applicable.

You could create a configuration class that has attributes.
 A user would only need to assign to the params that they
want to update.  If you change the names you could add
properties to deal with backwards compatibility.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 11:48

Message:
Logged In: YES 
user_id=995755

I agree the API for make_file() and make_table() has alot of
optional parameters that can look daunting.  The alternative
of providing accessor methods is less appealing to me.  It
sounds like Jim & I are in agreement on this.

As far as the compromise of making the templates private
members, I am assuming Jim is in favor of it.  I'm in favor
of them being members, it doesn't matter to me if they are
private.  I'll wait until Raymond weighs in on this one
before I move on it.

Jim -- Thanks for your input.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 11:17

Message:
Logged In: YES 
user_id=764593

For a context or unified diff, you don't really need to 
parametrize it very much.  Having a much larger API for side-
by-side puts things out of balance, which can make side-by-
side look either more difficult or preferred.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 09:57

Message:
Logged In: YES 
user_id=995755

Maybe a good compromise would be to leave them members of
the class but name them to imply they are private (add a
leading underscore).  That way if someone wants to create
their own subclass they can at their own risk.  They can
always write a little extra logic to insure the interface
didn't change and raise a custom exception explaining what
happened and what they need to look at.

I didn't read (2) in Raymond's comments.  Could you expand
on those concerns?


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-23 09:24

Message:
Logged In: YES 
user_id=764593

I agree that users should be able to override the template.

I think Raymond was concerned about 

(1) backwards compatibility if you want to change the 
interface.  For instance, you might later decide that there 
should be separate templates for header/footer/match section/
changed line/added line/deleted line.

(2) matching the other diff options, so this doesn't look far 
more complicated.

Unfortunately, at the moment I don't see a good way to solve 
those; using a private member and access functions wouldn't 
really simplify things much.



----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-23 07:53

Message:
Logged In: YES 
user_id=995755

I intend on implementing all the suggestions from the last
two comment submissions when I hear back from Raymond
Hettinger.  I'm questioning making the templates private
global variables.  I intentionally made them members of a
class so that they could be overridden when the class is
subclassed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 09:12

Message:
Logged In: YES 
user_id=80475

Unfortunately, I do not have time to give this more review.

Several thoughts:
- consider making mdiff as private.  that will leave its API
flexible to accomodate future changes
- move the templates to private global variables and work to
improve their indentation so that the html is readable
- inline the code for _escape from sax.  the three replaces
are not worth the interdependency
- the methods work fine with properly formatted input but
crash badly when the newlines have been stripped.  So,
either make the code more flexible or add error handling.
- overall, nice job.


----------------------------------------------------------------------

Comment By: Adam Souzis (asouzis)
Date: 2004-07-17 15:12

Message:
Logged In: YES 
user_id=57486

The diffs look cool but if the to and from lines are
identical an exception is thrown:

  File "", line 23, in makeDiff
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1687, in make_file
    summary=summary))
  File "c:\_dev\rx4rdf\rx\htmldiff.py", line 1741, in make_table
    if not diff_flags[0]:
IndexError: list index out of range

(This is on python 2.3.3 -- I renamed your difflib.py to
htmldiff.py and put it in site-packages)

Perhaps you should add the case of two identical files to
test_difflib.py.

thanks

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:16

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-16 05:13

Message:
Logged In: YES 
user_id=995755

Since I have not gotten any feedback on the user interface I 
took the liberty to tweek it the best I thought how.  Since I 
consider this new functionality very solid I went ahead and 
created changes to the documentation and test suite.

Per Martin v. L?wis (loewis) instructions I generated a patch 
which hopefully meets his needs.  My CVS access is limited to 
the web interface and thus the patch is based on the latest 
checked in as of today:

python/python/dist/src/Lib/difflib.py -- rev 1.21
python/python/dist/src/Tools/scripts/diff.py -- rev 1.2
python/python/dist/src/Lib/test/test_difflib.py -- rev 1.10
python/python/dist/src/Doc/lib/libdifflib.tex -- rev 1.17

Note, I am not very familiar with .tex but it seemed straight 
forward.  I editted the file by hand and it should be very close 
to what I intended.  Unfortunately I am not set up to convert 
the .tex to HTML.  I may try that next week.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 02:30

Message:
Logged In: YES 
user_id=21627

The pack lacks changes to the documentation (libdifflib.tex)
and changes to the test suite. Please always submit patches
as single unified or context diffs, rather than zip files of
the revised files.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-07-02 14:17

Message:
Logged In: YES 
user_id=995755

With the updated patch code I just posted, both full and
contextual differences pass the validator.w3.org check
(XHTML 1.0 Transitional).  Also the extra carriage returns
put in by DOS were removed from the difflib.py patch.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-25 14:01

Message:
Logged In: YES 
user_id=89016

Submitting difflib_context.html to validator.w3.org gives 2333 
errors. The character encoding is missing and there's no 
DOCTYPE declaration. The rest of the errors seem to be 
mostly related to the nowrap attribute (which must be written 
as nowrap="nowrap", as this is the only allowed value). 
Furthermore the patch contains a mix of CR and CRLF 
terminated lines.

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-06-24 02:23

Message:
Logged In: YES 
user_id=995755

I just attached an updated patch.  I based the patch on 
diff.py(CVS1.1) and difflib.py(CVS1.20) which was the latest I 
saw today on viewCVS.

The following enhancements were made:
1) user interface greatly simplified for generating HTML (see 
diff.py for example)
2) generated HTML now 4.01 Transitional compliant (so says 
HTML Tidy)
3) HTML color scheme for differences now matches that used 
by viewCVS.
4) differences table now has a row for each line making the 
HTML less susceptible to browser quirks.
5) took care of all issues to date enumerated here in this 
patch.

It would be great if I could get some help on:
A) getting some JavaScript? written to be able to select and 
cut text from a single column (right now text is selected from 
the whole row including both "from" and "to" text and line 
numbers.
B) solving the line width issue.  Currently the "from" / "to" 
column is as wide as the widest line.  Any ideas on wrapping 
or scrolling?

As of now the only feature I may want to add in the near 
future is optional tab expansion.

Thanks to those that have commented here and emailed me 
with suggestions and advice!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-11 10:35

Message:
Logged In: YES 
user_id=764593

Thank you; I have often wished for side-by-side, but not quite 
badly enough to write it.

That said, I would recommend some tweaks to the formatting.

"font" is deprecated; "span" would be better. 

On my display, the "next" lines don't always seem to be 
counted (except the first one), so that the anchors column is 
not lined up with the others.  (This would also be fixed by the 
separate rows suggestion.)

Ideally, the line numbers would be in a separate column from 
the code, to make cut'n'paste easier.  (Then you could replace 
font.num (or span.num) with td.linenum.)

Ideally, each change group should be a separate row in the 
table.  (I realize that this probably means a two-layer iterator, 
so that the line breaks and blank lines can be inserted 
correctly in the code columns.)


----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-29 00:30

Message:
Logged In: YES 
user_id=995755

Also, I will need to submit the fix for making it behave nice 
when there are no differences!!

----------------------------------------------------------------------

Comment By: Dan Gass (dmgass)
Date: 2004-04-09 09:30

Message:
Logged In: YES 
user_id=995755

In the time since submission I've found that the interface to 
the chgFmt and lineFmt functions (arguments of mdiff) should 
include both the line number and an indication of side 
(from/to).  The use for it I've found is for dropping anchors 
into the generated markup that it can be hyperlinked from 
elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 04:47:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 04:47:10 2004
Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation
Message-ID: 

Patches item #936813, was opened at 2004-04-17 04: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=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: Tim Peters (tim_one)
Date: 2004-08-29 22: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 18: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 04: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 15: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 07: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 23: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 04: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 Aug 30 12:23:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 12:23:47 2004
Subject: [Patches] [ python-Patches-941486 ] Fixes for bug 940578 (glob.glob
	on broken symlinks)
Message-ID: 

Patches item #941486, was opened at 2004-04-24 22:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: Fixes for bug 940578 (glob.glob on broken symlinks)

Initial Comment:
This does minimal changes to fix the bug.
It implements a function similar to `os.path.exists()`
but using
`os.lstat()` that doesn't fail on broken symlinks. 
This function would more properly belong in `posix`. 
This patch is good if you want to avoid API changes,
e.g. for backporting the fix.
Test case and doc fix (to make the behavior on broken
symlinks clear) are included.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 12:23

Message:
Logged In: YES 
user_id=469548

Well, no problem with python-dev: just checked in
glob-pathfix.diff.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-22 12:55

Message:
Logged In: YES 
user_id=469548

Hmm, it _is_ less efficient. I also looked through the
standard library and found another two modules which could
probably use this (tarfile.py and tempfile.py), so lexists
seems mildly useful after all. I'll ask on python-dev for
approval.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-08-22 00:19

Message:
Logged In: YES 
user_id=36166

This will indeed fix the bug.  The only technical problem is that it is less efficient (does two stat calls, trying ``lstat(path)`` does one).
The point of adding a new library function was that IMHO it would be no less useful on average than the behavior of `os.path.exists()`.  There must be other code which could benefit from an obvious way to do it.
Also, having two "sister" functions would encourage people to think which behavior for symlinks is more appropriate in their case, instead of automatically using  `os.path.exists()`.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-20 17:39

Message:
Logged In: YES 
user_id=469548

Is there any problem with just using 'if
os.path.islink(pathname) or os.path.exists(pathname)'? It
passes your test and it avoids adding a new function to
os.path. I've attached a patch using this. I'll check it in
if you don't have a problem with this.

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-27 11:35

Message:
Logged In: YES 
user_id=36166

Uploaded two fixes to glob-pathfix:

- Added ``lexists = exists`` to plat-riscos/riscospath.py
(forgot it previously).

- Switched to implementing `lexists` with `os.lstat` in
macpath.py.  It has a non-trivial `islink`, so it might need
it (or might not; I have no Mac access so I can't tell). 
Better safe than sorry (if somebody knows it's redudadnt,
feel  free to revert to  ``lexists = exists``...).

----------------------------------------------------------------------

Comment By: Cherniavsky Beni (cben)
Date: 2004-04-24 23:25

Message:
Logged In: YES 
user_id=36166

The second patch, glob-pathfix.diff, does the right thing by
adding `lexists` to `os.path` - it has no less right to be
there than `exists`.
It's implemented with `os.lstat()` in `posixpath`, alias to
`exists` in other `*path` modules.  **Please verify that
this is sufficient - it seems that no other platfrom has a
`os.lstat` that is not equivallent to `os.stat` but I can't
be sure.**

The glob.py bugfix then is a trivial  change from
``os.path.exists``
to ``os.path.lexists``.
Testcases and doc additions included.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941486&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 13:00:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 13:00:57 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-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  Mon Aug 30 15:31:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 15:31:51 2004
Subject: [Patches] [ python-Patches-1003640 ] fix for bugs 976878, 926369,
	875404 (pdb bkpt handling)
Message-ID: 

Patches item #1003640, was opened at 2004-08-05 01:23
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for bugs 976878, 926369, 875404 (pdb bkpt handling)

Initial Comment:
This patch fixes the following bugs:

#976878 PDB: unreliable breakpoints on functions      
       
#926369 pdb sets breakpoints in the wrong location
#875404 global stmt causes breakpoints to be ignored  
       


Discussion:

all 3 bugs are caused by  faults in pdb.checkline()
logic when it tries to  determine the first executable
line of a function body.

checkline() did its job by doing basic parsing of the
function body. The parsing was missing quite a few
cases where checkline()  returned either a wrong or
non-executable line of code...

The problem only happened when a breakpoint was set via
function name:
"b some_func"


Solution:

Instead of attempting to fix checkline() the patch
instead changes the breakpoint logic as follows

1) When a breakpoint is set via a func tionname 
   1a) the bkpt gets the lineno of the def  statement
thus eliminating the parsing logic in checkline()
  1b) a new funcname attribute is attached to the
breakpoint

2)  bdb.break_here() is changed to detect and handle 2
special cases
   2a) def statement is executed...No breakpoint is needed
   2b) a first executable line of a function with such
a breakpoint is reached.  Break is neded


Overall line count in pdb+bdb has actually gone down
slightly and  I think this solution is cleaner than
attempting to expand parsing in  checkline()..



----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 15:31

Message:
Logged In: YES 
user_id=469548

Checked in as rev 1.45 of bdb.py and rev 1.69 pdb.py with
some modifications to comments and docstrings. Thanks for
the patch!

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-25 02:53

Message:
Logged In: YES 
user_id=971153

attaching the new patch

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-22 18:32

Message:
Logged In: YES 
user_id=971153

I am attaching a new version of the patch.

In addition to issues raised earlier the v1 version of patch
had a couple of other problems:

1. funcname based breakpoints got a wrong hit statistics
(hit counter was incremented on every effective() call,
which happened for every line of a function with a funcname
bkpt)

2. If a user set a bkpt via line number at def statement
(this is probably quite rare, but still possible) , then pdb
would stop at every line of that function when the function
is called

To fix these I had to move most of funcname handling logic
from break_here() into a separate function
(bdb.checkfuncname) and call it from bdb.effective()

Changes in the new version include: 

1. Fix the issues with statistics and bkpts at def stmt

2. Fix a doc line of checkline()

3. Rename .breakingline into .func_first_executable_line

4. Comment fixes


----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-15 05:30

Message:
Logged In: YES 
user_id=971153

Ok, I'll submit an updated patch hopefully by the end of the
next week (I will be out of town for the next few days).

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-14 12:40

Message:
Logged In: YES 
user_id=469548

"Well, I am not sure: func_firstlineno causes a wrong
association with co_firstlineno (while these are almost
never the same)."

Ah, I misread the patch there. How about
func_first_executable_lineno (or something like that)? Or am
I off-base again?

"Would the following be better?"

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 
"

Yes. I was just having a bit of a hard time following your
patch. I think this is clearer.

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-08-13 21:24

Message:
Logged In: YES 
user_id=971153


>- The checkline() docstring needs to be updated.
>- Try not to use multi-line comments after a statement
>(e.g.: 'return False #it's not a func call, but rather', etc.).

Ok, I can resubmit a patch for these two


>- For consistency, Breakpoint.breakingline should probably
>be called func_firstlineno.

Well, I am not sure: func_firstlineno causes a wrong
association with
co_firstlineno (while these are almost never the same).
Furthermore,
the  name ".breakingline" reflects the purpose: "a line
number where to break", while, "func_firstlineno" is totatly
neutral..
 

>- Moving the 'bp.breakingline=frame.f_lineno' statement into
>an else: branch of the 'if bp.breakingline and
>(bp.breakingline != frame.f_lineno)' statement would
>probably make the logic clearer.

Are you suggesting to replace:

                if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
                bp.breakingline=frame.f_lineno

with:

               if bp.breakingline and (bp.breakingline !=
frame.f_lineno):
                    return False 
               else: 
                    bp.breakingline=frame.f_lineno

Why do you think it's better? It's definitely more verbose, has
an extra indentation level and looking through the code I
see a lot of code which looks like:

if  (....):
    return
foo
bar
without the else: branch


Would the following be better?

if not bp.breakingline:
      #the function is entered for the 1st time
      bp.breakingline=frame.f_lineno
if  bp.breakingline != frame.f_lineno:
       return False 

Thus making it explicit that there are really 2 decisions
being made:
1) do we need to set the breakingline
2) do we need to break here


I don't have any strong feelings regarding these 2 issues,
just want to make sure that I understand the problem





----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-13 17:13

Message:
Logged In: YES 
user_id=469548

The patch works for me (and any patch that fixes three bugs
should really be commited ), but I have some suggestions:

- The checkline() docstring needs to be updated.
- Try not to use multi-line comments after a statement
(e.g.: 'return False #it's not a func call, but rather', etc.).
- For consistency, Breakpoint.breakingline should probably
be called func_firstlineno.
- Moving the 'bp.breakingline=frame.f_lineno' statement into
an else: branch of the 'if bp.breakingline and
(bp.breakingline != frame.f_lineno)' statement would
probably make the logic clearer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1003640&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 16:50:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 16:50:42 2004
Subject: [Patches] [ python-Patches-1017405 ] bsddb's DB.keys() method
	ignores transaction argument
Message-ID: 

Patches item #1017405, was opened at 2004-08-27 02:01
Message generated for change (Comment added) made by kuran
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: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
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: Jp Calderone (kuran)
Date: 2004-08-30 10: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 12: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  Mon Aug 30 16:14:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 17:02:15 2004
Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug
	925628)
Message-ID: 

Patches item #934356, was opened at 2004-04-13 19:02
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: help on re-exported names (bug 925628)

Initial Comment:
help(module) only provides help on classes and functions 
that were first defined within the module.  For wrapper 
modules (like re), or partially-in-C modules (like socket)
this is not helpful.

The following patch changes pydoc(module) to document 
exactly the names listed in __all__, with a fallback to the 
current choices if __all__ is not defined.


----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 16:14

Message:
Logged In: YES 
user_id=469548

'if all is not None': explicit is better than implicit. I
checked this in as rev 1.98 of pydoc.py. Thanks for the patch!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-26 07:36

Message:
Logged In: YES 
user_id=764593

Yes, the earlier patch fixes most of this, and cleans up the 
remainder.  The only thing left is to make sure visiblename 
gets called on even imported objects.

Style question:  Should I use "if all" or "if all is not None".  

The only time it would make a difference is with an 
unusual imported special name.  (__*__, but not 
__builtins__, __doc__, __file__, __path__, __module__, 
or __name__).

Given that all has been bound to object.__all__ (or to 
None, in case of AttributeError), should I

(1)  Use "if all is not None or ..." to emphasize that I'm 
avoiding a special case (__all__ not defined) or
(2)  Use "if all or ..." because it is shorter


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 13:46

Message:
Logged In: YES 
user_id=469548

Right now all four hunks of the patch are failing for me
(probably because of #969938, which fixes part of the
problem). Could you update the patch to CVS HEAD and assign
to me afterwards? I'll take a good look at it then.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-16 22:23

Message:
Logged In: YES 
user_id=764593

Replacing with an improved version.  This is a diff to CVS 
head; users of Python 2.3 would have to either change the 
line numbers or also replace collections.deque.  (Setting deque 
to list was enough to allow testing.)

[Original patch had a problem with normal modules, but the 
exception was caught at a higher level, and *something* 
returned, so I didn't notice it at first.]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 18:48:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 18:48:06 2004
Subject: [Patches] [ python-Patches-934356 ] help on re-exported names (bug
	925628)
Message-ID: 

Patches item #934356, was opened at 2004-04-13 13:02
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470

Category: Library (Lib)
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: help on re-exported names (bug 925628)

Initial Comment:
help(module) only provides help on classes and functions 
that were first defined within the module.  For wrapper 
modules (like re), or partially-in-C modules (like socket)
this is not helpful.

The following patch changes pydoc(module) to document 
exactly the names listed in __all__, with a fallback to the 
current choices if __all__ is not defined.


----------------------------------------------------------------------

>Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-30 12:48

Message:
Logged In: YES 
user_id=764593

Thank you for applying it!

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-30 10:14

Message:
Logged In: YES 
user_id=469548

'if all is not None': explicit is better than implicit. I
checked this in as rev 1.98 of pydoc.py. Thanks for the patch!

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-26 01:36

Message:
Logged In: YES 
user_id=764593

Yes, the earlier patch fixes most of this, and cleans up the 
remainder.  The only thing left is to make sure visiblename 
gets called on even imported objects.

Style question:  Should I use "if all" or "if all is not None".  

The only time it would make a difference is with an 
unusual imported special name.  (__*__, but not 
__builtins__, __doc__, __file__, __path__, __module__, 
or __name__).

Given that all has been bound to object.__all__ (or to 
None, in case of AttributeError), should I

(1)  Use "if all is not None or ..." to emphasize that I'm 
avoiding a special case (__all__ not defined) or
(2)  Use "if all or ..." because it is shorter


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-08-21 07:46

Message:
Logged In: YES 
user_id=469548

Right now all four hunks of the patch are failing for me
(probably because of #969938, which fixes part of the
problem). Could you update the patch to CVS HEAD and assign
to me afterwards? I'll take a good look at it then.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-16 16:23

Message:
Logged In: YES 
user_id=764593

Replacing with an improved version.  This is a diff to CVS 
head; users of Python 2.3 would have to either change the 
line numbers or also replace collections.deque.  (Setting deque 
to list was enough to allow testing.)

[Original patch had a problem with normal modules, but the 
exception was caught at a higher level, and *something* 
returned, so I didn't notice it at first.]

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=934356&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 19:00:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 19:00:03 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 (Tracker Item Submitted) made by Item Submitter
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: Nobody/Anonymous (nobody)
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).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470
From noreply at sourceforge.net  Mon Aug 30 22:43:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Aug 30 22:43:56 2004
Subject: [Patches] [ python-Patches-1017405 ] bsddb's DB.keys() method
	ignores transaction argument
Message-ID: 

Patches item #1017405, was opened at 2004-08-27 08:01
Message generated for change (Settings changed) made by loewis
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: Open
Resolution: None
>Priority: 6
Submitted By: Jp Calderone (kuran)
>Assigned to: Martin v. L?wis (loewis)
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: Jp Calderone (kuran)
Date: 2004-08-30 16: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 18: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  Tue Aug 31 12:20:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 31 12:20:41 2004
Subject: [Patches] [ python-Patches-1007189 ] Multi-line imports
	implementation
Message-ID: 

Patches item #1007189, was opened at 2004-08-11 21:25
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
>Priority: 5
Submitted By: Dima Dorfman (ddorfman)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Multi-line imports implementation

Initial Comment:
Implementation of multi-line imports. As discussed on python-dev, 
this variant accepts

  from sys import (stdin, stdout)

but not

  from sys import (*)
  import (os)

or any variants thereof. This patch is intended to be complete and 
ready for commit after someone reviews it. The following files are 
machine-generated and need to be committed along with these 
changes, but they are not included in the diff:

  Lib/symbol.py Include/graminit.h Python/graminit.c

References:
http://mail.python.org/pipermail/python-dev/2004-August/047393.
html
(<20040809043104.GA82909@trit.org>) and followups, PEP 328


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-31 20:20

Message:
Logged In: YES 
user_id=29957

Checked into trunk - will be in Python 2.4a3. Thanks for the
implementation!

/cvsroot/python/python/dist/src/Doc/ref/ref6.tex,v  <-- 
ref6.tex
new revision: 1.72; previous revision: 1.71

/cvsroot/python/python/dist/src/Grammar/Grammar,v  <--  Grammar
new revision: 1.52; previous revision: 1.51

/cvsroot/python/python/dist/src/Include/graminit.h,v  <-- 
graminit.h
new revision: 2.23; previous revision: 2.22

/cvsroot/python/python/dist/src/Lib/symbol.py,v  <--  symbol.py
new revision: 1.18; previous revision: 1.17

/cvsroot/python/python/dist/src/Lib/compiler/transformer.py,v
 <--  transformer.py
new revision: 1.44; previous revision: 1.43

/cvsroot/python/python/dist/src/Lib/test/test_compile.py,v 
<--  test_compile.py
new revision: 1.23; previous revision: 1.22

/cvsroot/python/python/dist/src/Lib/test/test_grammar.py,v 
<--  test_grammar.py
new revision: 1.51; previous revision: 1.50

/cvsroot/python/python/dist/src/Lib/test/test_parser.py,v 
<--  test_parser.py
new revision: 1.20; previous revision: 1.19

/cvsroot/python/python/dist/src/Lib/test/output/test_grammar,v
 <--  test_grammar
new revision: 1.21; previous revision: 1.20

/cvsroot/python/python/dist/src/Misc/NEWS,v  <--  NEWS
new revision: 1.1125; previous revision: 1.1124

/cvsroot/python/python/dist/src/Modules/parsermodule.c,v 
<--  parsermodule.c
new revision: 2.85; previous revision: 2.84

/cvsroot/python/python/dist/src/Python/compile.c,v  <-- 
compile.c
new revision: 2.326; previous revision: 2.325

/cvsroot/python/python/dist/src/Python/future.c,v  <--  future.c
new revision: 2.14; previous revision: 2.13

/cvsroot/python/python/dist/src/Python/graminit.c,v  <-- 
graminit.c
new revision: 2.38; previous revision: 2.37



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-08-24 19:53

Message:
Logged In: YES 
user_id=29957

I'll be checking this in shortly.

(aside: please don't monkey with the priority settings...
thanks)


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-24 15:53

Message:
Logged In: YES 
user_id=908995

Is this patch waiting on anything else? Should I send out emails 
soliciting reviews from Fred and Jeremey?

Bumped priority since this should go in to the next alpha.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-14 20:14

Message:
Logged In: YES 
user_id=908995

Uploaded new patch. Changes:

  - Support trailing comma in from list (suggested by Michael
    Chermside on python-dev). This form is now acceptable:

      from os import (path,)

    but this is not:

      from os import path,

    I originally wanted to support the latter for consistency, but I
    don't think it's necessary (who would want to do that but not use
    parens?) and it's potentially confusing in a case like this:

      from sys import stdin,
      stdout

    which looks like it was intended to be one statement, but the
    second line is actually separate. The way the grammar is written,
    the case with a trailing comma but no parentheses parses okay, but
    it is intentionally rejected by the compiler.

  - Added more success and fail cases, incl. the "import (*)" case.

  - Added NEWS entry. (I'm uncertain whether providing this as part of
    a larger change actually helps; the file changes often enough that
    the patch stands a good chance of not applying cleanly.)

There should definitely be more docs, but I intentionally didn't try
to include unnecessary changes in this patch. As already mentioned,
that can be done later.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-08-14 00:56

Message:
Logged In: YES 
user_id=6380

+1 from a quick glance.

Missing a Misc/NEWS file update.

Suggestion: add "from sys import (*)" to the fail tests.

Please ask Fred to review the parser module changes.

Please ask Jeremy to review the compiler module changes.

Shouldn't there be more docs? Tutorial examples? Etc.

All that can be done after it's checked in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1007189&group_id=5470
From noreply at sourceforge.net  Tue Aug 31 16:19:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Aug 31 16:20:01 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 lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
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: 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 skenyeres at comcast.net  Tue Aug 31 23:28:01 2004
From: skenyeres at comcast.net (Susan E. Kenyeres)
Date: Tue Aug 31 23:28:05 2004
Subject: [Patches] RE:[1] 1mprove your-sperm morphology and quality...
	evenhanded bungled
Message-ID: 

An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/patches/attachments/20040831/88da35d6/attachment.html