From noreply at sourceforge.net Thu Jun 1 01:21:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 16:21:01 -0700 Subject: [Patches] [ python-Patches-1498571 ] Correctly unpickle exceptions Message-ID: Patches item #1498571, was opened at 2006-06-01 01:21 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=1498571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Correctly unpickle exceptions Initial Comment: With recent changes to exception types, unpickling exceptions that were pickled with an older version of Python didn't restore all of the original attributes. Example: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) ... >>> import pickle >>> f = open('jar', 'wb') >>> e = Exception('cucumbers', 'cabbage') >>> e.args ('cucumbers', 'cabbage') >>> pickle.dump(e, f) >>> f.close() >>> f = open('jar', 'rb') >>> e = pickle.load(f) >>> f.close() >>> e.args ('cucumbers', 'cabbage') Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24) ... >>> import pickle >>> f = open('jar', 'rb') >>> e = pickle.load(f) >>> f.close() >>> e.args () >>> e.__dict__['args'] ('cucumbers', 'cabbage') The attached patch fixes this problem, by adding a __setstate__ method to BaseException. I don't know if any new tests are needed, since pickling exceptions is already tested and new tests would require adding binary files to the test suite. I did some basic tests that I can attach if they are needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498571&group_id=5470 From noreply at sourceforge.net Thu Jun 1 03:36:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 18:36:37 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-06-01 02:41 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-06-01 10:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Thu Jun 1 03:44:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 18:44:39 -0700 Subject: [Patches] [ python-Patches-1498571 ] Correctly unpickle exceptions Message-ID: Patches item #1498571, was opened at 2006-06-01 01:21 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Correctly unpickle exceptions Initial Comment: With recent changes to exception types, unpickling exceptions that were pickled with an older version of Python didn't restore all of the original attributes. Example: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) ... >>> import pickle >>> f = open('jar', 'wb') >>> e = Exception('cucumbers', 'cabbage') >>> e.args ('cucumbers', 'cabbage') >>> pickle.dump(e, f) >>> f.close() >>> f = open('jar', 'rb') >>> e = pickle.load(f) >>> f.close() >>> e.args ('cucumbers', 'cabbage') Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24) ... >>> import pickle >>> f = open('jar', 'rb') >>> e = pickle.load(f) >>> f.close() >>> e.args () >>> e.__dict__['args'] ('cucumbers', 'cabbage') The attached patch fixes this problem, by adding a __setstate__ method to BaseException. I don't know if any new tests are needed, since pickling exceptions is already tested and new tests would require adding binary files to the test suite. I did some basic tests that I can attach if they are needed. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-06-01 03:44 Message: Logged In: YES user_id=1326842 Removed unnecessary cast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498571&group_id=5470 From noreply at sourceforge.net Thu Jun 1 05:28:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 20:28:35 -0700 Subject: [Patches] [ python-Patches-1498627 ] Fault in XMLRPC not always returned to client Message-ID: Patches item #1498627, was opened at 2006-05-31 23:28 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=1498627&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Savard (savardda) Assigned to: Nobody/Anonymous (nobody) Summary: Fault in XMLRPC not always returned to client Initial Comment: In XMLRPC communication, if an error occurs while decoding the stream, the Fault is not always returned to the client as a Fault object. This is a small mistake in the SimpleXMLRPCServer.py file where the decoding function is outside the try/catch but should be inside. A patch is included. Very simple so revision should be easy. Thanks, Daniel Savard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498627&group_id=5470 From noreply at sourceforge.net Thu Jun 1 08:39:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 31 May 2006 23:39:40 -0700 Subject: [Patches] [ python-Patches-1498571 ] Correctly unpickle exceptions Message-ID: Patches item #1498571, was opened at 2006-05-31 23:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Correctly unpickle exceptions Initial Comment: With recent changes to exception types, unpickling exceptions that were pickled with an older version of Python didn't restore all of the original attributes. Example: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) ... >>> import pickle >>> f = open('jar', 'wb') >>> e = Exception('cucumbers', 'cabbage') >>> e.args ('cucumbers', 'cabbage') >>> pickle.dump(e, f) >>> f.close() >>> f = open('jar', 'rb') >>> e = pickle.load(f) >>> f.close() >>> e.args ('cucumbers', 'cabbage') Python 2.5a2 (trunk:46539M, May 30 2006, 05:02:24) ... >>> import pickle >>> f = open('jar', 'rb') >>> e = pickle.load(f) >>> f.close() >>> e.args () >>> e.__dict__['args'] ('cucumbers', 'cabbage') The attached patch fixes this problem, by adding a __setstate__ method to BaseException. I don't know if any new tests are needed, since pickling exceptions is already tested and new tests would require adding binary files to the test suite. I did some basic tests that I can attach if they are needed. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 06:39 Message: Logged In: YES user_id=849994 Applied as rev. 46585. Thanks! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-01 01:44 Message: Logged In: YES user_id=1326842 Removed unnecessary cast. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498571&group_id=5470 From noreply at sourceforge.net Thu Jun 1 14:31:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 05:31:05 -0700 Subject: [Patches] [ python-Patches-1498627 ] Fault in XMLRPC not always returned to client Message-ID: Patches item #1498627, was opened at 2006-06-01 03:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498627&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Daniel Savard (savardda) Assigned to: Nobody/Anonymous (nobody) Summary: Fault in XMLRPC not always returned to client Initial Comment: In XMLRPC communication, if an error occurs while decoding the stream, the Fault is not always returned to the client as a Fault object. This is a small mistake in the SimpleXMLRPCServer.py file where the decoding function is outside the try/catch but should be inside. A patch is included. Very simple so revision should be easy. Thanks, Daniel Savard ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 12:31 Message: Logged In: YES user_id=849994 Thanks, fixed in rev. 46587. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498627&group_id=5470 From noreply at sourceforge.net Thu Jun 1 15:01:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:01:11 -0700 Subject: [Patches] [ python-Patches-1496135 ] Fix test_exceptions.py Message-ID: Patches item #1496135, was opened at 2006-05-27 20:10 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1496135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 3000 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Guido van Rossum (gvanrossum) Summary: Fix test_exceptions.py Initial Comment: The attached patch fixes a bug in Lib/test/test_exceptions.py related to the disappearance of apply() in Python 3000. The patch is against r46491. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 13:01 Message: Logged In: YES user_id=849994 Removed in rev. 46588 in 2.5 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1496135&group_id=5470 From noreply at sourceforge.net Thu Jun 1 15:19:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 06:19:50 -0700 Subject: [Patches] [ python-Patches-1497053 ] Let dicts propagate the exceptions in user __eq__ Message-ID: Patches item #1497053, was opened at 2006-05-29 16:54 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1497053&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Let dicts propagate the exceptions in user __eq__ Initial Comment: Patch for bug #1275608. Exceptions occurring when the dict lookup code calls a user-defined __eq__() are silently eaten. This has caused me several hours-long debugging session so far, so I thought that it was time to fix that. The proposed patch takes an easy route: it doesn't try to change PyDict_GetItem(), which still has no way to report exceptions and just eats them. Instead, it moves the exception-eating logic into PyDict_GetItem(). So all other ways in which dicts are accessed now correctly report exceptions. Most importantly, this includes all operators and methods accessible from Python code, including the 'x=d[key]' syntax. The only incompatibility I could imagine from this would be from code that relies on the fact that dicts were previouly tolerant about exceptions: an __eq__ could fail in any way, and the lookup would consider it as a "not equal" signal and proceed. I'd say "fix that". However it means that the 2.4 patch attached here should probably not be applied, sadly. I'd vote to check in the 2.5 patch as soon as possible. Note that these patches sneak in another bugfix patch too (#1456209) because I couldn't be bothered to maintain two mutually-conflicting patches. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-01 13:19 Message: Logged In: YES user_id=4771 Checked in as r46589. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-05-29 17:47 Message: Logged In: YES user_id=4771 Updated the patches; added more tests for 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1497053&group_id=5470 From noreply at sourceforge.net Thu Jun 1 17:21:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 08:21:36 -0700 Subject: [Patches] [ python-Patches-1498930 ] Generate from Unicode database instead of manualy coding. Message-ID: Patches item #1498930, was opened at 2006-06-01 17:21 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=1498930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anders Chrigstr?m (andersch) Assigned to: Nobody/Anonymous (nobody) Summary: Generate from Unicode database instead of manualy coding. Initial Comment: This patch makes _PyUnicode_IsLinebreak, _PyUnicode_ToNumeric and _PyUnicode_IsWhitespace generated from the Unicode database instead of being subject to manual updates. This ought to ease the transition to Unicode version 5.0.0. Allso, the definitions of whitespaces has changed between v3.2 and v4.1 so the test had to be updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498930&group_id=5470 From noreply at sourceforge.net Thu Jun 1 17:39:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 08:39:54 -0700 Subject: [Patches] [ python-Patches-1498930 ] Generate from Unicode database instead of manualy coding. Message-ID: Patches item #1498930, was opened at 2006-06-01 15:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anders Chrigstr?m (andersch) >Assigned to: Martin v. L??wis (loewis) Summary: Generate from Unicode database instead of manualy coding. Initial Comment: This patch makes _PyUnicode_IsLinebreak, _PyUnicode_ToNumeric and _PyUnicode_IsWhitespace generated from the Unicode database instead of being subject to manual updates. This ought to ease the transition to Unicode version 5.0.0. Allso, the definitions of whitespaces has changed between v3.2 and v4.1 so the test had to be updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498930&group_id=5470 From noreply at sourceforge.net Thu Jun 1 17:53:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 08:53:13 -0700 Subject: [Patches] [ python-Patches-1497053 ] Let dicts propagate the exceptions in user __eq__ Message-ID: Patches item #1497053, was opened at 2006-05-29 12:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1497053&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Let dicts propagate the exceptions in user __eq__ Initial Comment: Patch for bug #1275608. Exceptions occurring when the dict lookup code calls a user-defined __eq__() are silently eaten. This has caused me several hours-long debugging session so far, so I thought that it was time to fix that. The proposed patch takes an easy route: it doesn't try to change PyDict_GetItem(), which still has no way to report exceptions and just eats them. Instead, it moves the exception-eating logic into PyDict_GetItem(). So all other ways in which dicts are accessed now correctly report exceptions. Most importantly, this includes all operators and methods accessible from Python code, including the 'x=d[key]' syntax. The only incompatibility I could imagine from this would be from code that relies on the fact that dicts were previouly tolerant about exceptions: an __eq__ could fail in any way, and the lookup would consider it as a "not equal" signal and proceed. I'd say "fix that". However it means that the 2.4 patch attached here should probably not be applied, sadly. I'd vote to check in the 2.5 patch as soon as possible. Note that these patches sneak in another bugfix patch too (#1456209) because I couldn't be bothered to maintain two mutually-conflicting patches. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-01 11:53 Message: Logged In: YES user_id=31435 Thank you! Marking as Closed. I made a few minor changes (you checked it in while I was reviewing the patch), but you won't object to them ;-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-01 09:19 Message: Logged In: YES user_id=4771 Checked in as r46589. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-05-29 13:47 Message: Logged In: YES user_id=4771 Updated the patches; added more tests for 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1497053&group_id=5470 From noreply at sourceforge.net Thu Jun 1 21:14:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 12:14:11 -0700 Subject: [Patches] [ python-Patches-1497053 ] Let dicts propagate the exceptions in user __eq__ Message-ID: Patches item #1497053, was opened at 2006-05-29 16:54 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1497053&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Let dicts propagate the exceptions in user __eq__ Initial Comment: Patch for bug #1275608. Exceptions occurring when the dict lookup code calls a user-defined __eq__() are silently eaten. This has caused me several hours-long debugging session so far, so I thought that it was time to fix that. The proposed patch takes an easy route: it doesn't try to change PyDict_GetItem(), which still has no way to report exceptions and just eats them. Instead, it moves the exception-eating logic into PyDict_GetItem(). So all other ways in which dicts are accessed now correctly report exceptions. Most importantly, this includes all operators and methods accessible from Python code, including the 'x=d[key]' syntax. The only incompatibility I could imagine from this would be from code that relies on the fact that dicts were previouly tolerant about exceptions: an __eq__ could fail in any way, and the lookup would consider it as a "not equal" signal and proceed. I'd say "fix that". However it means that the 2.4 patch attached here should probably not be applied, sadly. I'd vote to check in the 2.5 patch as soon as possible. Note that these patches sneak in another bugfix patch too (#1456209) because I couldn't be bothered to maintain two mutually-conflicting patches. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-01 19:14 Message: Logged In: YES user_id=4771 Oups, I left an 'unsigned int' by mistake. Thanks. (Sidenotedly, you and me closed all three related SF trackers at about the same time, so I guess it's why each of us thinks he's the one that closed them :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-01 15:53 Message: Logged In: YES user_id=31435 Thank you! Marking as Closed. I made a few minor changes (you checked it in while I was reviewing the patch), but you won't object to them ;-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-01 13:19 Message: Logged In: YES user_id=4771 Checked in as r46589. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-05-29 17:47 Message: Logged In: YES user_id=4771 Updated the patches; added more tests for 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1497053&group_id=5470 From noreply at sourceforge.net Thu Jun 1 21:32:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 12:32:55 -0700 Subject: [Patches] [ python-Patches-1498441 ] Change *args from a tuple to list Message-ID: Patches item #1498441, was opened at 2006-05-31 15:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498441&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Guido van Rossum (gvanrossum) Summary: Change *args from a tuple to list Initial Comment: As discussed on python-3000, this patch changes *args from a tuple to a list. It also includes doc and test changes. The patch is against r46582. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-01 15:32 Message: Logged In: YES user_id=1344176 As requested by Neal Norwitz, some benchmarking (all times in usecs per loop): ./python -mtimeit 'def foo(*args): pass' 'foo()' As tuple: 1.56 As list: 1.7 ./python -mtimeit 'def foo(*args): pass' 'foo(1)' As tuple: 1.75 As list: 2.04 ./python -mtimeit 'def foo(*args): pass' 'foo(1, 2)' As tuple: 1.87 As list: 2.15 ./python -mtimeit 'def foo(*args): pass' 'foo(1, 2, 3)' As tuple: 1.95 As list: 2.3 ./python -mtimeit 'def foo(*args): pass' 'foo(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)' As tuple: 2.67 As list: 2.97 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498441&group_id=5470 From noreply at sourceforge.net Thu Jun 1 22:03:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 13:03:08 -0700 Subject: [Patches] [ python-Patches-1499095 ] Optimise "in" operations on tuples of consts Message-ID: Patches item #1499095, was opened at 2006-06-01 16: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=1499095&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Optimise "in" operations on tuples of consts Initial Comment: The following patch adds a peephole optimisation to the compiler that optimises expressions like x in (5, 6, 7) to x in frozenset([5, 6, 7]) That is, any "in" operation on tuples of constants will be optimised to "in" operations on frozensets. Note that the patch does not handle lists, as "in [constant list]" is already optimised to "in (constant tuple)". Additional tests for Lib/test/test_peepholer.py are included. This patch is against r46597. Some benchmarks (all times in usecs per loop): ./python -mtimeit '5 in (5, 6, 7, 8, 9)' Unoptimised: 0.376 Optimised: 0.437 ./python -mtimeit '9 in (5, 6, 7, 8, 9)' Unoptimised: 1.14 Optimised: 0.436 ./python -mtimeit '89 in (5, 6, 7, 8, 9)' Unoptimised: 1.32 Optimised: 0.498 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499095&group_id=5470 From noreply at sourceforge.net Fri Jun 2 08:00:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 23:00:49 -0700 Subject: [Patches] [ python-Patches-1499095 ] Optimise "in" operations on tuples of consts Message-ID: Patches item #1499095, was opened at 2006-06-01 20:03 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499095&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Optimise "in" operations on tuples of consts Initial Comment: The following patch adds a peephole optimisation to the compiler that optimises expressions like x in (5, 6, 7) to x in frozenset([5, 6, 7]) That is, any "in" operation on tuples of constants will be optimised to "in" operations on frozensets. Note that the patch does not handle lists, as "in [constant list]" is already optimised to "in (constant tuple)". Additional tests for Lib/test/test_peepholer.py are included. This patch is against r46597. Some benchmarks (all times in usecs per loop): ./python -mtimeit '5 in (5, 6, 7, 8, 9)' Unoptimised: 0.376 Optimised: 0.437 ./python -mtimeit '9 in (5, 6, 7, 8, 9)' Unoptimised: 1.14 Optimised: 0.436 ./python -mtimeit '89 in (5, 6, 7, 8, 9)' Unoptimised: 1.32 Optimised: 0.498 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499095&group_id=5470 From noreply at sourceforge.net Fri Jun 2 08:23:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Jun 2006 23:23:52 -0700 Subject: [Patches] [ python-Patches-1357836 ] potential crash and free memory read Message-ID: Patches item #1357836, was opened at 2005-11-15 21:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1357836&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. L??wis (loewis) Summary: potential crash and free memory read Initial Comment: Martin, I think this problem came about from the work on PEP 263 (coding spec). Attached is a patch that corrects a free memory write. The problem shows up with valgrind and test_coding IIRC. There is a XXX comment in the code which points to another problem. It's possible that you could break and not do a strcpy(). Or perhaps decoding_fgets() shouldn't call error_ret(). I'm not sure if error_ret() should free the buffer ever. I think that would be my preference. That way we can deallocate it where we allocate it. I think I plugged all the other leaks. Let me know what you think. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-01 23:23 Message: Logged In: YES user_id=33168 Someone already fixed the XXX comment. Apply the rest of the patch. This should be backported to 2.4. Committed revision 46602. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1357836&group_id=5470 From noreply at sourceforge.net Fri Jun 2 22:46:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Jun 2006 13:46:25 -0700 Subject: [Patches] [ python-Patches-1499797 ] Fix for memory leak in WindowsError_str Message-ID: Patches item #1499797, was opened at 2006-06-02 22: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=1499797&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for memory leak in WindowsError_str Initial Comment: The same memory leak that Neal Norwitz found in EnvironmentError_str is also present in WindowsError_str. How to reproduce: Python 2.5a2 (trunk:46603M, Jun 2 2006, 22:37:47) ... >>> e = WindowsError(1, 'message', 'filename') [27062 refs] >>> s = str(e) [27065 refs] >>> s = str(e) [27066 refs] >>> s = str(e) [27067 refs] >>> del e.filename [27066 refs] >>> s = str(e) [27066 refs] >>> s = str(e) [27066 refs] >>> s = str(e) [27066 refs] This simple patch fixes it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499797&group_id=5470 From noreply at sourceforge.net Sat Jun 3 09:01:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 00:01:51 -0700 Subject: [Patches] [ python-Patches-1490384 ] PC new-logo-based icon set Message-ID: Patches item #1490384, was opened at 2006-05-17 18:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490384&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Andrew Clover (bobince) Assigned to: Martin v. L??wis (loewis) Summary: PC new-logo-based icon set Initial Comment: Following positive discussion on -dev, here's the updated version of the PC/py*.ico files I hacked up a while ago. The attachment is a ZIP, not a patch, as it contains only binaries. Also available as tgz: http://doxdesk.com/img/software/py/win32-icons.tar.gz Also possibly of interest: http://doxdesk.com/img/software/py/icons3.zip This attachment contains only the simple replacement files; the icons3 ZIP also contains: - source - versions including Windows Vista large icons (probably not worth including at this point as they're quite sizable and no-one is using Vista yet) - an egg icon (there is currently no installer/shell support for eggs, but could be worth adding in future) - a new installer side banner (this has not currently seen any discussion on -dev, but may be worth considering if the intention is to leave behind the purple/green snake branding) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-03 09:01 Message: Logged In: YES user_id=21627 Hmm, I'm getting an http error 404 when accessing http://doxdesk.com/img/software/py/win32-icons2.zip ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-30 18:20 Message: Logged In: YES user_id=311085 No probs and ta! However... I've got more altered icons, attached and at http://doxdesk.com/img/software/py/win32-icons2.zip . Sorry for the inconvenience - pretty sure these are 'final'. The problem with the old files? Well it seems there's a bug in Windows that can cause redraw errors on 32-bit alpha-blended XP icons. I can't find any doc on this at all, but from experiment it seems that it can occur when icons are partially redrawn instead of drawn all at once. This is most easily provoked by slowly dragging a window on top of an Explorer window in Tiles/Icons/List mode, to reveal the icon underneath. It looks to be an arithmetic overflow in compositing: when a nearly-transparent white pixel being plotted onto pure white background in this partial-redraw code, a black pixel can unexpectedly result, with poor-looking results. (Thanks, Windows.) I've hacked the bitmaps to avoid places where they're white-and-transparent enough to be able to provoke this aggravating occasional behaviour. Also while I'm at it, I've removed the 256 colour 48x48 icons, since it saves a few K and there's almost no practical case where they're of benefit. cheers, ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-28 18:58 Message: Logged In: YES user_id=21627 Committed the rest as r46503. Thanks again! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-26 19:02 Message: Logged In: YES user_id=21627 Ok, I will then do the following changes still: - add baselogo.svg and source.xar (ignore all the other files), - remove the attribution for Erik (sorry for missing that) ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-26 04:50 Message: Logged In: YES user_id=311085 > I put a demo installer containing them Seems to work OK. The thanks at the end still attributes the graphic to Erik though; I'm not after an ack there myself, but changing the text to not imply the current graphic is his one may be appropriate. > baselogo.svg; I assume this is a source file Yes. This is just the Python logo itself (the gradient version as used on the new website), in vector format. > icons.svgz; can't figure out what this is Same as source.xar, but exported as W3C standard SVG format for wider compatibility [compressed, hence the 'z']. Unfortunately because SVG cannot reproduce some of effects used, and because the SVG export path is currently quite bad, it's not really directly usable, but it might be of use to anyone who wants to hack on the graphics but doesn't use Xara. > source.xar; not sure either This is the primary vector graphics source of the icons - the other SVG and PNG files are just there because other people requested them. It's in Xara format, a previously proprietary graphics application which has now gone open-source and is heading rapidly towards being usable on Linux, but isn't quite there yet. > a directory called png, with many png file - I expect > that these aren't source files, are they? Nope, they're just exactly the same content as in the (with-vista) .ico files, just supplied as PNG for anyone who wants to fiddle with them in a more accessible bitmap format. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-22 10:56 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed it as r46063. I put a demo installer containing them at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13290.msi I would also like to add the source files, but I have difficulties figuring out what they are. There is a source directory; with: - baselogo.svg; I assume this is a source file - icons.svgz; can't figure out what this is - source.xar; not sure either - a directory called png, with many png file - I expect that these aren't source files, are they? ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-19 16:21 Message: Logged In: YES user_id=311085 Sure, no worries. I'll fax over the -python version since I have ancient contributions to cover too. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-19 13:22 Message: Logged In: YES user_id=21627 Thanks! Are you willing to contribute them to the PSF, under the terms of the contributor agreement at http://www.python.org/psf/contrib/contrib-form/ ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490384&group_id=5470 From noreply at sourceforge.net Sat Jun 3 09:29:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 00:29:23 -0700 Subject: [Patches] [ python-Patches-1490384 ] PC new-logo-based icon set Message-ID: Patches item #1490384, was opened at 2006-05-17 16:59 Message generated for change (Comment added) made by bobince You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490384&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Andrew Clover (bobince) Assigned to: Martin v. L??wis (loewis) Summary: PC new-logo-based icon set Initial Comment: Following positive discussion on -dev, here's the updated version of the PC/py*.ico files I hacked up a while ago. The attachment is a ZIP, not a patch, as it contains only binaries. Also available as tgz: http://doxdesk.com/img/software/py/win32-icons.tar.gz Also possibly of interest: http://doxdesk.com/img/software/py/icons3.zip This attachment contains only the simple replacement files; the icons3 ZIP also contains: - source - versions including Windows Vista large icons (probably not worth including at this point as they're quite sizable and no-one is using Vista yet) - an egg icon (there is currently no installer/shell support for eggs, but could be worth adding in future) - a new installer side banner (this has not currently seen any discussion on -dev, but may be worth considering if the intention is to leave behind the purple/green snake branding) ---------------------------------------------------------------------- >Comment By: Andrew Clover (bobince) Date: 2006-06-03 07:29 Message: Logged In: YES user_id=311085 Oh! Sorry - it's there now, and attached, as I had meant to do originally. No changes to any of the source files, as it's purely a .ICO-level fix. Cheers, ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-03 07:01 Message: Logged In: YES user_id=21627 Hmm, I'm getting an http error 404 when accessing http://doxdesk.com/img/software/py/win32-icons2.zip ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-30 16:20 Message: Logged In: YES user_id=311085 No probs and ta! However... I've got more altered icons, attached and at http://doxdesk.com/img/software/py/win32-icons2.zip . Sorry for the inconvenience - pretty sure these are 'final'. The problem with the old files? Well it seems there's a bug in Windows that can cause redraw errors on 32-bit alpha-blended XP icons. I can't find any doc on this at all, but from experiment it seems that it can occur when icons are partially redrawn instead of drawn all at once. This is most easily provoked by slowly dragging a window on top of an Explorer window in Tiles/Icons/List mode, to reveal the icon underneath. It looks to be an arithmetic overflow in compositing: when a nearly-transparent white pixel being plotted onto pure white background in this partial-redraw code, a black pixel can unexpectedly result, with poor-looking results. (Thanks, Windows.) I've hacked the bitmaps to avoid places where they're white-and-transparent enough to be able to provoke this aggravating occasional behaviour. Also while I'm at it, I've removed the 256 colour 48x48 icons, since it saves a few K and there's almost no practical case where they're of benefit. cheers, ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-28 16:58 Message: Logged In: YES user_id=21627 Committed the rest as r46503. Thanks again! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-26 17:02 Message: Logged In: YES user_id=21627 Ok, I will then do the following changes still: - add baselogo.svg and source.xar (ignore all the other files), - remove the attribution for Erik (sorry for missing that) ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-26 02:50 Message: Logged In: YES user_id=311085 > I put a demo installer containing them Seems to work OK. The thanks at the end still attributes the graphic to Erik though; I'm not after an ack there myself, but changing the text to not imply the current graphic is his one may be appropriate. > baselogo.svg; I assume this is a source file Yes. This is just the Python logo itself (the gradient version as used on the new website), in vector format. > icons.svgz; can't figure out what this is Same as source.xar, but exported as W3C standard SVG format for wider compatibility [compressed, hence the 'z']. Unfortunately because SVG cannot reproduce some of effects used, and because the SVG export path is currently quite bad, it's not really directly usable, but it might be of use to anyone who wants to hack on the graphics but doesn't use Xara. > source.xar; not sure either This is the primary vector graphics source of the icons - the other SVG and PNG files are just there because other people requested them. It's in Xara format, a previously proprietary graphics application which has now gone open-source and is heading rapidly towards being usable on Linux, but isn't quite there yet. > a directory called png, with many png file - I expect > that these aren't source files, are they? Nope, they're just exactly the same content as in the (with-vista) .ico files, just supplied as PNG for anyone who wants to fiddle with them in a more accessible bitmap format. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-22 08:56 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed it as r46063. I put a demo installer containing them at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13290.msi I would also like to add the source files, but I have difficulties figuring out what they are. There is a source directory; with: - baselogo.svg; I assume this is a source file - icons.svgz; can't figure out what this is - source.xar; not sure either - a directory called png, with many png file - I expect that these aren't source files, are they? ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-19 14:21 Message: Logged In: YES user_id=311085 Sure, no worries. I'll fax over the -python version since I have ancient contributions to cover too. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-19 11:22 Message: Logged In: YES user_id=21627 Thanks! Are you willing to contribute them to the PSF, under the terms of the contributor agreement at http://www.python.org/psf/contrib/contrib-form/ ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490384&group_id=5470 From noreply at sourceforge.net Sat Jun 3 09:42:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 00:42:47 -0700 Subject: [Patches] [ python-Patches-1490384 ] PC new-logo-based icon set Message-ID: Patches item #1490384, was opened at 2006-05-17 18:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490384&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Andrew Clover (bobince) Assigned to: Martin v. L??wis (loewis) Summary: PC new-logo-based icon set Initial Comment: Following positive discussion on -dev, here's the updated version of the PC/py*.ico files I hacked up a while ago. The attachment is a ZIP, not a patch, as it contains only binaries. Also available as tgz: http://doxdesk.com/img/software/py/win32-icons.tar.gz Also possibly of interest: http://doxdesk.com/img/software/py/icons3.zip This attachment contains only the simple replacement files; the icons3 ZIP also contains: - source - versions including Windows Vista large icons (probably not worth including at this point as they're quite sizable and no-one is using Vista yet) - an egg icon (there is currently no installer/shell support for eggs, but could be worth adding in future) - a new installer side banner (this has not currently seen any discussion on -dev, but may be worth considering if the intention is to leave behind the purple/green snake branding) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-03 09:42 Message: Logged In: YES user_id=21627 Thanks, committed as 46610. ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-06-03 09:29 Message: Logged In: YES user_id=311085 Oh! Sorry - it's there now, and attached, as I had meant to do originally. No changes to any of the source files, as it's purely a .ICO-level fix. Cheers, ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-03 09:01 Message: Logged In: YES user_id=21627 Hmm, I'm getting an http error 404 when accessing http://doxdesk.com/img/software/py/win32-icons2.zip ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-30 18:20 Message: Logged In: YES user_id=311085 No probs and ta! However... I've got more altered icons, attached and at http://doxdesk.com/img/software/py/win32-icons2.zip . Sorry for the inconvenience - pretty sure these are 'final'. The problem with the old files? Well it seems there's a bug in Windows that can cause redraw errors on 32-bit alpha-blended XP icons. I can't find any doc on this at all, but from experiment it seems that it can occur when icons are partially redrawn instead of drawn all at once. This is most easily provoked by slowly dragging a window on top of an Explorer window in Tiles/Icons/List mode, to reveal the icon underneath. It looks to be an arithmetic overflow in compositing: when a nearly-transparent white pixel being plotted onto pure white background in this partial-redraw code, a black pixel can unexpectedly result, with poor-looking results. (Thanks, Windows.) I've hacked the bitmaps to avoid places where they're white-and-transparent enough to be able to provoke this aggravating occasional behaviour. Also while I'm at it, I've removed the 256 colour 48x48 icons, since it saves a few K and there's almost no practical case where they're of benefit. cheers, ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-28 18:58 Message: Logged In: YES user_id=21627 Committed the rest as r46503. Thanks again! ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-26 19:02 Message: Logged In: YES user_id=21627 Ok, I will then do the following changes still: - add baselogo.svg and source.xar (ignore all the other files), - remove the attribution for Erik (sorry for missing that) ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-26 04:50 Message: Logged In: YES user_id=311085 > I put a demo installer containing them Seems to work OK. The thanks at the end still attributes the graphic to Erik though; I'm not after an ack there myself, but changing the text to not imply the current graphic is his one may be appropriate. > baselogo.svg; I assume this is a source file Yes. This is just the Python logo itself (the gradient version as used on the new website), in vector format. > icons.svgz; can't figure out what this is Same as source.xar, but exported as W3C standard SVG format for wider compatibility [compressed, hence the 'z']. Unfortunately because SVG cannot reproduce some of effects used, and because the SVG export path is currently quite bad, it's not really directly usable, but it might be of use to anyone who wants to hack on the graphics but doesn't use Xara. > source.xar; not sure either This is the primary vector graphics source of the icons - the other SVG and PNG files are just there because other people requested them. It's in Xara format, a previously proprietary graphics application which has now gone open-source and is heading rapidly towards being usable on Linux, but isn't quite there yet. > a directory called png, with many png file - I expect > that these aren't source files, are they? Nope, they're just exactly the same content as in the (with-vista) .ico files, just supplied as PNG for anyone who wants to fiddle with them in a more accessible bitmap format. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-22 10:56 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed it as r46063. I put a demo installer containing them at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13290.msi I would also like to add the source files, but I have difficulties figuring out what they are. There is a source directory; with: - baselogo.svg; I assume this is a source file - icons.svgz; can't figure out what this is - source.xar; not sure either - a directory called png, with many png file - I expect that these aren't source files, are they? ---------------------------------------------------------------------- Comment By: Andrew Clover (bobince) Date: 2006-05-19 16:21 Message: Logged In: YES user_id=311085 Sure, no worries. I'll fax over the -python version since I have ancient contributions to cover too. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-19 13:22 Message: Logged In: YES user_id=21627 Thanks! Are you willing to contribute them to the PSF, under the terms of the contributor agreement at http://www.python.org/psf/contrib/contrib-form/ ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490384&group_id=5470 From noreply at sourceforge.net Sat Jun 3 10:22:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 01:22:08 -0700 Subject: [Patches] [ python-Patches-1499095 ] Optimise "in" operations on tuples of consts Message-ID: Patches item #1499095, was opened at 2006-06-01 15:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499095&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Optimise "in" operations on tuples of consts Initial Comment: The following patch adds a peephole optimisation to the compiler that optimises expressions like x in (5, 6, 7) to x in frozenset([5, 6, 7]) That is, any "in" operation on tuples of constants will be optimised to "in" operations on frozensets. Note that the patch does not handle lists, as "in [constant list]" is already optimised to "in (constant tuple)". Additional tests for Lib/test/test_peepholer.py are included. This patch is against r46597. Some benchmarks (all times in usecs per loop): ./python -mtimeit '5 in (5, 6, 7, 8, 9)' Unoptimised: 0.376 Optimised: 0.437 ./python -mtimeit '9 in (5, 6, 7, 8, 9)' Unoptimised: 1.14 Optimised: 0.436 ./python -mtimeit '89 in (5, 6, 7, 8, 9)' Unoptimised: 1.32 Optimised: 0.498 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-03 03:22 Message: Logged In: YES user_id=80475 Sorry, this enticing idea has already been explored and rejected. This is issue is that the transformation is not semanatically neutral. Currently, writing "{} in (1,2,3)" returns False, but after the transformation would raise an exception, "TypeError: dict objects are unhashable". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499095&group_id=5470 From noreply at sourceforge.net Sun Jun 4 01:51:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 16:51:23 -0700 Subject: [Patches] [ python-Patches-1346214 ] Better dead code elimination for the AST compiler Message-ID: Patches item #1346214, was opened at 2005-11-02 10:21 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Neal Norwitz (nnorwitz) Summary: Better dead code elimination for the AST compiler Initial Comment: Here's a patch that adds dead code elimination for if 0: style statements, and improves the current dead code elimination for while statements by not performing elimination if the function is a generator. If the last yield statement from a generator is removed, the generator is turned into a regular function, which changes the semantics of the function. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-03 16:51 Message: Logged In: YES user_id=357491 Replied on python-dev, but for thoroughness, the patch looks fine from looking at the patch file itself. Apply the 'return' detection on its own, though, for better tracking of changes and easier rollback if something does go bad. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-26 04:34 Message: Logged In: YES user_id=849994 Attaching new patch which does elimination for if 0, if 1 and if __debug__ correctly (visiting else clauses!) and correctly recognizes functions mixing "return x" and "yield". ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-06 12:41 Message: Logged In: YES user_id=858364 Sorry, I'm new to the sourceforge patch tracker. The patch should be attached now. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 11:08 Message: Logged In: YES user_id=750513 the actual patch is missing.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 From noreply at sourceforge.net Sun Jun 4 08:07:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 23:07:28 -0700 Subject: [Patches] [ python-Patches-1346214 ] Better dead code elimination for the AST compiler Message-ID: Patches item #1346214, was opened at 2005-11-02 10:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Rune Holm (titanstar) >Assigned to: Georg Brandl (gbrandl) Summary: Better dead code elimination for the AST compiler Initial Comment: Here's a patch that adds dead code elimination for if 0: style statements, and improves the current dead code elimination for while statements by not performing elimination if the function is a generator. If the last yield statement from a generator is removed, the generator is turned into a regular function, which changes the semantics of the function. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-03 23:07 Message: Logged In: YES user_id=33168 It would be nice to make a #define for the error message so they don't get out of sync. I wouldn't mind seeing the variable name spelled out, ste_returns_value or something like that. I didn't look closely at the line numbers and verify the changes were correct. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-03 16:51 Message: Logged In: YES user_id=357491 Replied on python-dev, but for thoroughness, the patch looks fine from looking at the patch file itself. Apply the 'return' detection on its own, though, for better tracking of changes and easier rollback if something does go bad. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-26 04:34 Message: Logged In: YES user_id=849994 Attaching new patch which does elimination for if 0, if 1 and if __debug__ correctly (visiting else clauses!) and correctly recognizes functions mixing "return x" and "yield". ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-06 12:41 Message: Logged In: YES user_id=858364 Sorry, I'm new to the sourceforge patch tracker. The patch should be attached now. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 11:08 Message: Logged In: YES user_id=750513 the actual patch is missing.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 From noreply at sourceforge.net Sun Jun 4 08:20:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Jun 2006 23:20:12 -0700 Subject: [Patches] [ python-Patches-1499797 ] Fix for memory leak in WindowsError_str Message-ID: Patches item #1499797, was opened at 2006-06-02 13:46 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499797&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ?iga Seilnacht (zseil) >Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for memory leak in WindowsError_str Initial Comment: The same memory leak that Neal Norwitz found in EnvironmentError_str is also present in WindowsError_str. How to reproduce: Python 2.5a2 (trunk:46603M, Jun 2 2006, 22:37:47) ... >>> e = WindowsError(1, 'message', 'filename') [27062 refs] >>> s = str(e) [27065 refs] >>> s = str(e) [27066 refs] >>> s = str(e) [27067 refs] >>> del e.filename [27066 refs] >>> s = str(e) [27066 refs] >>> s = str(e) [27066 refs] >>> s = str(e) [27066 refs] This simple patch fixes it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-03 23:20 Message: Logged In: YES user_id=33168 Thanks! Committed revision 46639. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1499797&group_id=5470 From noreply at sourceforge.net Sun Jun 4 10:19:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 01:19:08 -0700 Subject: [Patches] [ python-Patches-1496952 ] Convert Tkinter to METH_VARARGS style Message-ID: Patches item #1496952, was opened at 2006-05-29 16:04 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1496952&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: Convert Tkinter to METH_VARARGS style Initial Comment: Patch attached. Martin, as the maintainer please check. I also changed some PyTuple_Size and PyTuple_GetItem to the corresponding macros when tupleness is guaranteed. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 10:19 Message: Logged In: YES user_id=21627 The patch is wrong: .call() might get called with a single argument which is a tuple; this should be treated the same as if multiple arguments had been passed. Please leave out the unrelated changes to the tuple API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1496952&group_id=5470 From noreply at sourceforge.net Sun Jun 4 16:50:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 07:50:18 -0700 Subject: [Patches] [ python-Patches-1500504 ] Alternate RFC 3896 compliant URI parsing module Message-ID: Patches item #1500504, was opened at 2006-06-05 00: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=1500504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Alternate RFC 3896 compliant URI parsing module Initial Comment: Inspired by (and based on) Paul Jimenez's uriparse module (http://python.org/sf/1462525), urischemes tries to put a cleaner interface in front of the URI parsing engine. Most of the module works with a URI subclass of tuple that is always a 5-tuple (scheme, authority, path, query, fragment). The authority component is either None, or a URIAuthority subclass of tuple that is always a 4-tuple (user, password, host, port). The function make_uri will create a URI string from the 5 constituent components of a URI. The components do not need to be strings - if they are not strings, str() will be invoked on them (this allows the URIAuthority tuple subclass to be used transparently instead of a string for the authority component). The result is checked to ensure it is an RFC-compliant URI. The function split_uri accepts a string and returns a URI object with strings as the individual elements. Invoking str() on this object will recreate a URI string using make_uri(). The regex underlying this operation is now broken out and available as module level attributes like URI_PATTERN. The functions split_authority and make_authority are similar, only working solely on the authority component rather than the whole URI. The function parse_uri digs into the internal structure of a URI, also parsing the components. This will replace a non-empty URI authority component string with a URIAuthority tuple subclass. Depending on the scheme, it may also replace other components (e.g. for mailto links, the path is replaced with a (user, host) tuple subclass). The main parsing engine is still URIParser (much the same as Paul's), but the root of the internal parser hierarchy is now SchemeParser. This has two subclasses, URLParser and MailtoParser. The various URL flavours are now different instances of URLParser rather than subclasses. All of the actual parsers are available as module level attributes with the same name as the scheme they parse. Additionally, each parser knows the name of the scheme it is intended to parse. The parse() methods of the individual parsers are now expected to return a URI object (SchemeParser actually takes care of this). The parse() method also takes a dictionary of defaults, which can override the defaults supplied by the parser instance. The unparse() method is gone - instead, the scheme parser should ensure that all components returned are either strings or produce the right thing when __str__ is invoked (e.g. see _MailtoURIPath) The module level 'schemes' attribute is a mapping from scheme names to parsers that is automatically populated with all instances of SchemeParser that are found in the module globals() urljoin has been renamed to join_uri to match the style of the other names in the module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 From noreply at sourceforge.net Sun Jun 4 21:37:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 12:37:47 -0700 Subject: [Patches] [ python-Patches-1359618 ] Speed charmap encoder Message-ID: Patches item #1359618, was opened at 2005-11-18 09:00 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359618&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. L??wis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Speed charmap encoder Initial Comment: This patch speeds up the charmap encoder by a factor of 4 to 5, using a trie structure instead of a dictionary; the speedup primarily comes from not creating integer objects in the process. The trie is created by inverting the encoding map; the codec generator is changed to drop the encoding dictionary, and instead emit a function call to create the trie. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-04 21:37 Message: Logged In: YES user_id=21627 Thanks for all comments and reviews; I have now committed the patch as r46648. This includes a regeneration of the individual codecs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-05-26 14:00 Message: Logged In: YES user_id=38388 Hi Martin, I've only had a quick look at the patch, but it looks nice, so please check it in. Don't we also have to regenerate all the codecs once this patch has been applied ?! If so, I can take care of that using Makefile approach in Tools/unicode/. Please let me know. Thanks. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-05-26 00:45 Message: Logged In: YES user_id=591932 Updated the patch as part of NeedForSpeed (mainly Py_ssize_t changes and some rejected chunks) Because the previous version on the trunk was broken I'm not sure what to compare the results against ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359618&group_id=5470 From noreply at sourceforge.net Sun Jun 4 21:40:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 12:40:32 -0700 Subject: [Patches] [ python-Patches-1500504 ] Alternate RFC 3986 compliant URI parsing module Message-ID: Patches item #1500504, was opened at 2006-06-04 16:50 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) >Summary: Alternate RFC 3986 compliant URI parsing module Initial Comment: Inspired by (and based on) Paul Jimenez's uriparse module (http://python.org/sf/1462525), urischemes tries to put a cleaner interface in front of the URI parsing engine. Most of the module works with a URI subclass of tuple that is always a 5-tuple (scheme, authority, path, query, fragment). The authority component is either None, or a URIAuthority subclass of tuple that is always a 4-tuple (user, password, host, port). The function make_uri will create a URI string from the 5 constituent components of a URI. The components do not need to be strings - if they are not strings, str() will be invoked on them (this allows the URIAuthority tuple subclass to be used transparently instead of a string for the authority component). The result is checked to ensure it is an RFC-compliant URI. The function split_uri accepts a string and returns a URI object with strings as the individual elements. Invoking str() on this object will recreate a URI string using make_uri(). The regex underlying this operation is now broken out and available as module level attributes like URI_PATTERN. The functions split_authority and make_authority are similar, only working solely on the authority component rather than the whole URI. The function parse_uri digs into the internal structure of a URI, also parsing the components. This will replace a non-empty URI authority component string with a URIAuthority tuple subclass. Depending on the scheme, it may also replace other components (e.g. for mailto links, the path is replaced with a (user, host) tuple subclass). The main parsing engine is still URIParser (much the same as Paul's), but the root of the internal parser hierarchy is now SchemeParser. This has two subclasses, URLParser and MailtoParser. The various URL flavours are now different instances of URLParser rather than subclasses. All of the actual parsers are available as module level attributes with the same name as the scheme they parse. Additionally, each parser knows the name of the scheme it is intended to parse. The parse() methods of the individual parsers are now expected to return a URI object (SchemeParser actually takes care of this). The parse() method also takes a dictionary of defaults, which can override the defaults supplied by the parser instance. The unparse() method is gone - instead, the scheme parser should ensure that all components returned are either strings or produce the right thing when __str__ is invoked (e.g. see _MailtoURIPath) The module level 'schemes' attribute is a mapping from scheme names to parsers that is automatically populated with all instances of SchemeParser that are found in the module globals() urljoin has been renamed to join_uri to match the style of the other names in the module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:21:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:21:08 -0700 Subject: [Patches] [ python-Patches-1500609 ] Remove dependencies on the sets module Message-ID: Patches item #1500609, was opened at 2006-06-04 16:21 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=1500609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove dependencies on the sets module Initial Comment: The attached patch removes several lingering dependencies on the deprecated sets module, replacing them with usages of the now-builtin set type. The patch is against r46648. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500609&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:38:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:38:12 -0700 Subject: [Patches] [ python-Patches-1500611 ] (py3k) Remove the sets module Message-ID: Patches item #1500611, was opened at 2006-06-04 16:38 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=1500611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: (py3k) Remove the sets module Initial Comment: This patch removes the sets module, its documentation and tests, in addition to replacing all usages of it with the built-in set type. The patch is against r46648. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500611&group_id=5470 From noreply at sourceforge.net Sun Jun 4 22:54:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 13:54:02 -0700 Subject: [Patches] [ python-Patches-1500623 ] Remove the repr()-backticks Message-ID: Patches item #1500623, was opened at 2006-06-04 16:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove the repr()-backticks Initial Comment: This patch removes parser support for backticks, the UNARY_CONVERT opcode and all usages of the repr()-backticks. It also adds a test to test_syntax to make sure the backticks really are gone. The patch is against r46648. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500623&group_id=5470 From noreply at sourceforge.net Sun Jun 4 23:57:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 14:57:53 -0700 Subject: [Patches] [ python-Patches-1346214 ] Better dead code elimination for the AST compiler Message-ID: Patches item #1346214, was opened at 2005-11-02 18:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Georg Brandl (gbrandl) Summary: Better dead code elimination for the AST compiler Initial Comment: Here's a patch that adds dead code elimination for if 0: style statements, and improves the current dead code elimination for while statements by not performing elimination if the function is a generator. If the last yield statement from a generator is removed, the generator is turned into a regular function, which changes the semantics of the function. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-04 21:57 Message: Logged In: YES user_id=849994 Added your suggestions and committed as rev. 46650. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-04 06:07 Message: Logged In: YES user_id=33168 It would be nice to make a #define for the error message so they don't get out of sync. I wouldn't mind seeing the variable name spelled out, ste_returns_value or something like that. I didn't look closely at the line numbers and verify the changes were correct. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-03 23:51 Message: Logged In: YES user_id=357491 Replied on python-dev, but for thoroughness, the patch looks fine from looking at the patch file itself. Apply the 'return' detection on its own, though, for better tracking of changes and easier rollback if something does go bad. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-26 11:34 Message: Logged In: YES user_id=849994 Attaching new patch which does elimination for if 0, if 1 and if __debug__ correctly (visiting else clauses!) and correctly recognizes functions mixing "return x" and "yield". ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-06 20:41 Message: Logged In: YES user_id=858364 Sorry, I'm new to the sourceforge patch tracker. The patch should be attached now. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 19:08 Message: Logged In: YES user_id=750513 the actual patch is missing.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346214&group_id=5470 From noreply at sourceforge.net Mon Jun 5 08:35:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Jun 2006 23:35:27 -0700 Subject: [Patches] [ python-Patches-1500773 ] wm_attributes doesn't take keyword arguments Message-ID: Patches item #1500773, was opened at 2006-06-04 23: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=1500773&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L??wis (loewis) Summary: wm_attributes doesn't take keyword arguments Initial Comment: The Tk wm attributes command takes option arguments (from the Tk wm manual page): wm attributes window ?option value option value...? And option arguments are normally given with keyword arguments in Tkinter (most if not all widget creation functions and widget commands). The attached patch changes the wm_attributes method to take keyword arguments, so top.wm_attributes(alpha=.8) will work as expected (on Windows XP and Mac OS X). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500773&group_id=5470 From noreply at sourceforge.net Mon Jun 5 10:16:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 01:16:02 -0700 Subject: [Patches] [ python-Patches-1500815 ] AF_NETLINK support for socket module Message-ID: Patches item #1500815, was opened at 2006-06-05 18:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: AF_NETLINK support for socket module Initial Comment: I noticed that the socket module contains the AF_NETLINK constant, but that it was missing the code to make it work. Here's a patch to add netlink socket support. AF_NETLINK is used on Linux as a means of communication between the kernel and user processes (though it can actually be used between user processes too). See the netlink(7) manpage for some more details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500815&group_id=5470 From noreply at sourceforge.net Mon Jun 5 12:46:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 03:46:34 -0700 Subject: [Patches] [ python-Patches-1454485 ] patch for SIGSEGV in arraymodule.c Message-ID: Patches item #1454485, was opened at 2006-03-20 13:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Baris Metin (tbmetin) Assigned to: Martin v. L??wis (loewis) Summary: patch for SIGSEGV in arraymodule.c Initial Comment: Array module fails handling utf-8 strings giving a SIGSEGV. Attached patch seems to do the trick... gdb> run (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1480337216 (LWP 31303)] Python 2.4.2 (#1, Mar 20 2006, 12:08:06) [GCC 3.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import array >>> x = array.array("u") >>> x.append(u"bar????") Traceback (most recent call last): File "", line 1, in ? TypeError: array item must be unicode character >>> x.append("bar????") >>> x Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480337216 (LWP 31303)] Error while running hook_stop: Invalid type combination in ordering comparison. 0xa7ee0799 in PyUnicodeUCS4_FromUnicode () from /usr/lib/libpython2.4.so.1.0 ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-05 12:46 Message: Logged In: YES user_id=21627 I added a work-around for the crash in r46669: PyUnicode_FromUnicode now only uses the shared characters for non-negative values. Every other patch I thought of would have broken backwards compatibility in some way. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-14 07:22 Message: Logged In: YES user_id=33168 I removed the code which tried to convert a buffer (string) to unicode. Committed revision 45374. We still have to address 2.4. Martin, I can make the fix if you tell me what to do. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 09:16 Message: Logged In: YES user_id=21627 It turns out that the test whether wchar_t is unsigned was reversed. Correcting the test stops makes the program not crash anymore; this is fixed in r45264 Not sure whether this can be backported to 2.4; it will mean that Python will stop using wchar_t as Py_UNICODE on Linux. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-29 20:13 Message: Logged In: YES user_id=21627 I think there is a design choice here: Should it be an invariant that all characters in a Unicode string are below sys.maxunicode? If so, the procedures to create them should check whether that invariant holds. If not, all code that deals with them most consider cases where they are larger than sys.maxunicode or smaller than 0. Also, should it be a requirement that Py_UNICODE is an unsigned type? Then tests for <0 could be dropped, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-29 09:52 Message: Logged In: YES user_id=33168 Attached is an updated patch to only do the (unsigned) cast in unicodeobject.c. The test included in the patch still crashes the interpreter, this time in unicodectype.c. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-26 23:36 Message: Logged In: YES user_id=21627 The second part of the patch (checking that *u is not negative) is definitely right. The first part (requiring an even number of bytes for a u# argument) probably requires discussion on python-dev (or this patch should be assigned to MAL): I don't think it should be allowed to pass a non-Unicode object to u# in the first place. In particular, if you pass a byte string, there would be an implicit assumption that the byte encoding is the same internal representation as a Py_UNICODE. This is bad - Python normally assumes the encoding of a string is the system encoding, which normally is ASCII. Of course, changing the call to a type error for 2.4.3 probably won't work, either, because it might break existing code. Anyway, I believe the latter fix alone should fix the crash: the current getargs implementation will round down to the next multiple of sizeof(Py_UNICODE), thanks the integer division. u_setitem will then refuse the call if the length is not 1. IOW, it is possible to append between 4 and 7 bytes to a Unicode array. I wonder why the patch fixes the problem: *u should be an unsigned, and comparing an unsigned with a signed should convert the signed to unsigned, no? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-25 08:29 Message: Logged In: YES user_id=33168 Verified for 2.4 and head. The probably could exist w/ucs2 also if you use 'bar' (I think). I agree with Nick, this patch doesn't really solve the problem. The attached patch fixes the crash more generally, but I'm think there is a better solution. I hope Martin has time to review this and suggest a better fix. Martin, the change in getargs ensures that we don't try to convert an 8-bit string of length 5 to unicode. The change in unicodeobject ensures that we don't reference the array with a negative offset as happens if the buffer conversion succeeds with an invalid unicode character. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-03-24 15:43 Message: Logged In: YES user_id=1038590 To get the effect of the patch, it should be sufficient to just change the format character to an uppercase U. That doesn't seem like the right fix though - the actual explosion isn't happening until later when the array elements are being converted to Unicode for output. ---------------------------------------------------------------------- Comment By: Baris Metin (tbmetin) Date: 2006-03-24 10:19 Message: Logged In: YES user_id=1045504 I'm able to reproduce the bug with 2.5a0 SVN (r43289). Please try with --enable-unicode=ucs4 The patch is against svn too.. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 07:11 Message: Logged In: YES user_id=33168 With the stock 2.4.2 on my linux box I was able to reproduce this. I couldn't reproduce with 2.4.3c1. Can you verify this is fixed in 2.4.3? Sagol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454485&group_id=5470 From noreply at sourceforge.net Mon Jun 5 15:53:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 06:53:15 -0700 Subject: [Patches] [ python-Patches-1500504 ] Alternate RFC 3986 compliant URI parsing module Message-ID: Patches item #1500504, was opened at 2006-06-05 00:50 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Alternate RFC 3986 compliant URI parsing module Initial Comment: Inspired by (and based on) Paul Jimenez's uriparse module (http://python.org/sf/1462525), urischemes tries to put a cleaner interface in front of the URI parsing engine. Most of the module works with a URI subclass of tuple that is always a 5-tuple (scheme, authority, path, query, fragment). The authority component is either None, or a URIAuthority subclass of tuple that is always a 4-tuple (user, password, host, port). The function make_uri will create a URI string from the 5 constituent components of a URI. The components do not need to be strings - if they are not strings, str() will be invoked on them (this allows the URIAuthority tuple subclass to be used transparently instead of a string for the authority component). The result is checked to ensure it is an RFC-compliant URI. The function split_uri accepts a string and returns a URI object with strings as the individual elements. Invoking str() on this object will recreate a URI string using make_uri(). The regex underlying this operation is now broken out and available as module level attributes like URI_PATTERN. The functions split_authority and make_authority are similar, only working solely on the authority component rather than the whole URI. The function parse_uri digs into the internal structure of a URI, also parsing the components. This will replace a non-empty URI authority component string with a URIAuthority tuple subclass. Depending on the scheme, it may also replace other components (e.g. for mailto links, the path is replaced with a (user, host) tuple subclass). The main parsing engine is still URIParser (much the same as Paul's), but the root of the internal parser hierarchy is now SchemeParser. This has two subclasses, URLParser and MailtoParser. The various URL flavours are now different instances of URLParser rather than subclasses. All of the actual parsers are available as module level attributes with the same name as the scheme they parse. Additionally, each parser knows the name of the scheme it is intended to parse. The parse() methods of the individual parsers are now expected to return a URI object (SchemeParser actually takes care of this). The parse() method also takes a dictionary of defaults, which can override the defaults supplied by the parser instance. The unparse() method is gone - instead, the scheme parser should ensure that all components returned are either strings or produce the right thing when __str__ is invoked (e.g. see _MailtoURIPath) The module level 'schemes' attribute is a mapping from scheme names to parsers that is automatically populated with all instances of SchemeParser that are found in the module globals() urljoin has been renamed to join_uri to match the style of the other names in the module. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-05 23:53 Message: Logged In: YES user_id=1038590 Updated version attached which addresses some issues raised by Mike Brown in private mail (the difference between a URI and a URI reference and some major differences between URI paths and posix paths). Also settled on split/join for the component separation and recombination operations and made the join methods all take a tuple so that join_x(split_x(uri)) round trips. Based on the terminology in the RFC, the function to combine a URI reference with a base URI is now called "resolve_uriref". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 From noreply at sourceforge.net Mon Jun 5 12:49:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 03:49:21 -0700 Subject: [Patches] [ python-Patches-1500815 ] AF_NETLINK support for socket module Message-ID: Patches item #1500815, was opened at 2006-06-05 10:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: AF_NETLINK support for socket module Initial Comment: I noticed that the socket module contains the AF_NETLINK constant, but that it was missing the code to make it work. Here's a patch to add netlink socket support. AF_NETLINK is used on Linux as a means of communication between the kernel and user processes (though it can actually be used between user processes too). See the netlink(7) manpage for some more details. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-05 12:49 Message: Logged In: YES user_id=21627 This patch is out of date; AF_NETLINK support was added with patch 1103116. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500815&group_id=5470 From noreply at sourceforge.net Mon Jun 5 21:15:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 12:15:07 -0700 Subject: [Patches] [ python-Patches-1501180 ] Cyclic garbage collection support for slices Message-ID: Patches item #1501180, was opened at 2006-06-05 21: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=1501180&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Cyclic garbage collection support for slices Initial Comment: Slice's members start, stop and step can be arbitrary python objects, which means that slices can be easily included in reference cycles (see the test in the patch). The patch includes the necessary changes to enable support for the gc. Since slices are immutable, there should be no need for a tp_clear method. I also changed the slice_dealloc function to use Py_CLEAR macros instead of Py_DECREF. I noticed that PySlice_GetIndices is still missing support for types with a __index__ method. I don't know if that is intentional or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 From noreply at sourceforge.net Mon Jun 5 22:12:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 13:12:28 -0700 Subject: [Patches] [ python-Patches-1491759 ] IDLE L&F on MacOSX Message-ID: Patches item #1491759, was opened at 2006-05-19 19:39 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE L&F on MacOSX Initial Comment: The attached patch fixes some L&F issues on MacOSX: - IDLE now reacts to file-open AppleEvents, which means that if a user associates IDLE.app with .py files IDLE will open .py files when the user double-clicks on them - Hide the tcl/tk console window that gets opened by default when IDLE is in an application bundle (that's a misfeature of aquatk) - Patch the menu's to make sure they better conform to the HIG. - PyShell/EditorWindow status_bar no longer overlaps with the resize widget in the lower-left corner of the window Open issues: - When you double-click on a file and IDLE is not yet open the file will be opened, but IDLE will open the default shell window just above it :-( - I'm not terribly happy with the code changes that implement the updated menu structure. - The default keybindings on OSX are the windows keybindings. I haven't checked yet if that can be fixed programmaticly, I also haven't verified if the macos keybindings are fully correct for OSX. - The general L&F is still wrong, but that isn't really IDLE's fault: tcl/tk doesn't fully conform to the HIG yet (dialogs without title bars, wrong default dinwos background, wrong widget for tabbed windows, ...). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-05 22:12 Message: Logged In: YES user_id=580910 I've updated the patch slightly: - ZoomHeight placed the top of the window behind the menubar - Keybindings that use the Alt don't work with AquaTk, automaticly replace those by bindings that use the Option key (which is basically the same key on OSX). This is needed because not all key-bindings are part of config- keys.def, some are in config-extensions.def. The annoying bit is that this doesn't actually solve the entire problem, now zooms windows as the menu suggests, but also still inserts the TM character (which is the default binding for in OSX text views). - Rename the Windows menu to Window (singular) to be more consistent with OSX naming of menus. I haven't found a nice way to override the default keybindings yet. I'm very tempted to patch the various configfiles when running a framework-install. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 14:28 Message: Logged In: YES user_id=580910 I've currently worked around the default keybindings issue by copying a mac- specific copy of config-main.def into the library directory when doing a framework install of python. That's obviously not a good solution, but I wouldn't know how to do it better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491759&group_id=5470 From noreply at sourceforge.net Mon Jun 5 23:12:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 14:12:17 -0700 Subject: [Patches] [ python-Patches-1501180 ] Cyclic garbage collection support for slices Message-ID: Patches item #1501180, was opened at 2006-06-05 21:15 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Cyclic garbage collection support for slices Initial Comment: Slice's members start, stop and step can be arbitrary python objects, which means that slices can be easily included in reference cycles (see the test in the patch). The patch includes the necessary changes to enable support for the gc. Since slices are immutable, there should be no need for a tp_clear method. I also changed the slice_dealloc function to use Py_CLEAR macros instead of Py_DECREF. I noticed that PySlice_GetIndices is still missing support for types with a __index__ method. I don't know if that is intentional or not. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-06-05 23:12 Message: Logged In: YES user_id=1326842 Updated a misleading comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 From noreply at sourceforge.net Mon Jun 5 23:27:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 14:27:32 -0700 Subject: [Patches] [ python-Patches-1501180 ] Cyclic garbage collection support for slices Message-ID: Patches item #1501180, was opened at 2006-06-05 15:15 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Cyclic garbage collection support for slices Initial Comment: Slice's members start, stop and step can be arbitrary python objects, which means that slices can be easily included in reference cycles (see the test in the patch). The patch includes the necessary changes to enable support for the gc. Since slices are immutable, there should be no need for a tp_clear method. I also changed the slice_dealloc function to use Py_CLEAR macros instead of Py_DECREF. I noticed that PySlice_GetIndices is still missing support for types with a __index__ method. I don't know if that is intentional or not. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-05 17:27 Message: Logged In: YES user_id=31435 No offense, but thrust of this seems goofy. Slice objects aren't sanely used as containers for arbitrary objects, they typically hold only integers and maybe None. The decision to leave them out of cyclic gc was therefore sensible; that they can be abused in strained ways to create cycles seems much more an exercise in determined perverseness than a practical concern. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-05 17:12 Message: Logged In: YES user_id=1326842 Updated a misleading comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 From noreply at sourceforge.net Mon Jun 5 23:36:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 14:36:40 -0700 Subject: [Patches] [ python-Patches-1501180 ] Cyclic garbage collection support for slices Message-ID: Patches item #1501180, was opened at 2006-06-05 21:15 Message generated for change (Settings changed) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Cyclic garbage collection support for slices Initial Comment: Slice's members start, stop and step can be arbitrary python objects, which means that slices can be easily included in reference cycles (see the test in the patch). The patch includes the necessary changes to enable support for the gc. Since slices are immutable, there should be no need for a tp_clear method. I also changed the slice_dealloc function to use Py_CLEAR macros instead of Py_DECREF. I noticed that PySlice_GetIndices is still missing support for types with a __index__ method. I don't know if that is intentional or not. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-06-05 23:36 Message: Logged In: YES user_id=1326842 OK, closing it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-06-05 23:27 Message: Logged In: YES user_id=31435 No offense, but thrust of this seems goofy. Slice objects aren't sanely used as containers for arbitrary objects, they typically hold only integers and maybe None. The decision to leave them out of cyclic gc was therefore sensible; that they can be abused in strained ways to create cycles seems much more an exercise in determined perverseness than a practical concern. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-06-05 23:12 Message: Logged In: YES user_id=1326842 Updated a misleading comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501180&group_id=5470 From noreply at sourceforge.net Tue Jun 6 08:21:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Jun 2006 23:21:12 -0700 Subject: [Patches] [ python-Patches-1491759 ] IDLE L&F on MacOSX Message-ID: Patches item #1491759, was opened at 2006-05-19 19:39 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE L&F on MacOSX Initial Comment: The attached patch fixes some L&F issues on MacOSX: - IDLE now reacts to file-open AppleEvents, which means that if a user associates IDLE.app with .py files IDLE will open .py files when the user double-clicks on them - Hide the tcl/tk console window that gets opened by default when IDLE is in an application bundle (that's a misfeature of aquatk) - Patch the menu's to make sure they better conform to the HIG. - PyShell/EditorWindow status_bar no longer overlaps with the resize widget in the lower-left corner of the window Open issues: - When you double-click on a file and IDLE is not yet open the file will be opened, but IDLE will open the default shell window just above it :-( - I'm not terribly happy with the code changes that implement the updated menu structure. - The default keybindings on OSX are the windows keybindings. I haven't checked yet if that can be fixed programmaticly, I also haven't verified if the macos keybindings are fully correct for OSX. - The general L&F is still wrong, but that isn't really IDLE's fault: tcl/tk doesn't fully conform to the HIG yet (dialogs without title bars, wrong default dinwos background, wrong widget for tabbed windows, ...). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-06 08:21 Message: Logged In: YES user_id=580910 Actually upload the new patch. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-05 22:12 Message: Logged In: YES user_id=580910 I've updated the patch slightly: - ZoomHeight placed the top of the window behind the menubar - Keybindings that use the Alt don't work with AquaTk, automaticly replace those by bindings that use the Option key (which is basically the same key on OSX). This is needed because not all key-bindings are part of config- keys.def, some are in config-extensions.def. The annoying bit is that this doesn't actually solve the entire problem, now zooms windows as the menu suggests, but also still inserts the TM character (which is the default binding for in OSX text views). - Rename the Windows menu to Window (singular) to be more consistent with OSX naming of menus. I haven't found a nice way to override the default keybindings yet. I'm very tempted to patch the various configfiles when running a framework-install. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 14:28 Message: Logged In: YES user_id=580910 I've currently worked around the default keybindings issue by copying a mac- specific copy of config-main.def into the library directory when doing a framework install of python. That's obviously not a good solution, but I wouldn't know how to do it better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491759&group_id=5470 From noreply at sourceforge.net Tue Jun 6 12:09:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 03:09:02 -0700 Subject: [Patches] [ python-Patches-1501534 ] Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Message-ID: Patches item #1501534, was opened at 2006-06-06 19: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=1501534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeung Mun Sic (ruseel) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Initial Comment: Fix Bug #1339007 I think that Bug #1339007 is making confusion in many places. http://www.google.com/search? hl=ko&newwindow=1&q=dbfilenameshelf+attributeerror&lr= lang_en%7Clang_ko http://mail.python.org/pipermail/python-list/2003- October/188138.html In my case, I ran into this bug with py-wordnet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 From noreply at sourceforge.net Tue Jun 6 12:11:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 03:11:49 -0700 Subject: [Patches] [ python-Patches-1501534 ] Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Message-ID: Patches item #1501534, was opened at 2006-06-06 19:09 Message generated for change (Settings changed) made by ruseel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Jeung Mun Sic (ruseel) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Initial Comment: Fix Bug #1339007 I think that Bug #1339007 is making confusion in many places. http://www.google.com/search? hl=ko&newwindow=1&q=dbfilenameshelf+attributeerror&lr= lang_en%7Clang_ko http://mail.python.org/pipermail/python-list/2003- October/188138.html In my case, I ran into this bug with py-wordnet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 From noreply at sourceforge.net Tue Jun 6 12:13:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 03:13:30 -0700 Subject: [Patches] [ python-Patches-1501534 ] Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Message-ID: Patches item #1501534, was opened at 2006-06-06 19:09 Message generated for change (Settings changed) made by ruseel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 5 Submitted By: Jeung Mun Sic (ruseel) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Initial Comment: Fix Bug #1339007 I think that Bug #1339007 is making confusion in many places. http://www.google.com/search? hl=ko&newwindow=1&q=dbfilenameshelf+attributeerror&lr= lang_en%7Clang_ko http://mail.python.org/pipermail/python-list/2003- October/188138.html In my case, I ran into this bug with py-wordnet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 From noreply at sourceforge.net Tue Jun 6 17:46:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 08:46:31 -0700 Subject: [Patches] [ python-Patches-1500504 ] Alternate RFC 3986 compliant URI parsing module Message-ID: Patches item #1500504, was opened at 2006-06-05 00:50 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Alternate RFC 3986 compliant URI parsing module Initial Comment: Inspired by (and based on) Paul Jimenez's uriparse module (http://python.org/sf/1462525), urischemes tries to put a cleaner interface in front of the URI parsing engine. Most of the module works with a URI subclass of tuple that is always a 5-tuple (scheme, authority, path, query, fragment). The authority component is either None, or a URIAuthority subclass of tuple that is always a 4-tuple (user, password, host, port). The function make_uri will create a URI string from the 5 constituent components of a URI. The components do not need to be strings - if they are not strings, str() will be invoked on them (this allows the URIAuthority tuple subclass to be used transparently instead of a string for the authority component). The result is checked to ensure it is an RFC-compliant URI. The function split_uri accepts a string and returns a URI object with strings as the individual elements. Invoking str() on this object will recreate a URI string using make_uri(). The regex underlying this operation is now broken out and available as module level attributes like URI_PATTERN. The functions split_authority and make_authority are similar, only working solely on the authority component rather than the whole URI. The function parse_uri digs into the internal structure of a URI, also parsing the components. This will replace a non-empty URI authority component string with a URIAuthority tuple subclass. Depending on the scheme, it may also replace other components (e.g. for mailto links, the path is replaced with a (user, host) tuple subclass). The main parsing engine is still URIParser (much the same as Paul's), but the root of the internal parser hierarchy is now SchemeParser. This has two subclasses, URLParser and MailtoParser. The various URL flavours are now different instances of URLParser rather than subclasses. All of the actual parsers are available as module level attributes with the same name as the scheme they parse. Additionally, each parser knows the name of the scheme it is intended to parse. The parse() methods of the individual parsers are now expected to return a URI object (SchemeParser actually takes care of this). The parse() method also takes a dictionary of defaults, which can override the defaults supplied by the parser instance. The unparse() method is gone - instead, the scheme parser should ensure that all components returned are either strings or produce the right thing when __str__ is invoked (e.g. see _MailtoURIPath) The module level 'schemes' attribute is a mapping from scheme names to parsers that is automatically populated with all instances of SchemeParser that are found in the module globals() urljoin has been renamed to join_uri to match the style of the other names in the module. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-07 01:46 Message: Logged In: YES user_id=1038590 Uploaded version 0.3 which passes all the RFC tests, as well as the failing 4Suite tests Mike sent me based on version 0.1 and 0.2. The last 4suite failure went away when I realised those tests expected to operate in strict mode :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-05 23:53 Message: Logged In: YES user_id=1038590 Updated version attached which addresses some issues raised by Mike Brown in private mail (the difference between a URI and a URI reference and some major differences between URI paths and posix paths). Also settled on split/join for the component separation and recombination operations and made the join methods all take a tuple so that join_x(split_x(uri)) round trips. Based on the terminology in the RFC, the function to combine a URI reference with a base URI is now called "resolve_uriref". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 From noreply at sourceforge.net Wed Jun 7 04:49:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 19:49:17 -0700 Subject: [Patches] [ python-Patches-1501979 ] syntax errors on continuation lines Message-ID: Patches item #1501979, was opened at 2006-06-06 16:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Miller (rcmiller) Assigned to: Nobody/Anonymous (nobody) Summary: syntax errors on continuation lines Initial Comment: This patch modifies syntax error location information to indicate when an error is detected on a statement continuation line, for example File "test.py", line 42 (continuing line 41) The intent is to be less confusing when an error reported on one line is actually the result of unbalanced brackets on a previous line. The change adds a new 'stmt_lineno' field to the SyntaxError exception, containing the line number on which the statement started. The patch is against r46701 and was developed and tested on Fedora 4 Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501979&group_id=5470 From noreply at sourceforge.net Wed Jun 7 05:09:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Jun 2006 20:09:24 -0700 Subject: [Patches] [ python-Patches-1501987 ] Remove randomness from test_exceptions Message-ID: Patches item #1501987, was opened at 2006-06-07 05: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=1501987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Remove randomness from test_exceptions Initial Comment: Recently test_exceptions was reporting random memory leaks. It seems that this was caused by the pickling part of testAttributes, which uses a random integer for pickling protocol. With this patch applied, I couldn't reproduce the leak anymore, although I didn't run it 666 times. The patch also includes a fix for the pickling part of the test (previously it was checking the attributes of the original exception, not the unpickled one), removes another unused import and moves all the imports to the top of the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501987&group_id=5470 From noreply at sourceforge.net Wed Jun 7 09:00:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 00:00:18 -0700 Subject: [Patches] [ python-Patches-1501987 ] Remove randomness from test_exceptions Message-ID: Patches item #1501987, was opened at 2006-06-06 23:09 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Remove randomness from test_exceptions Initial Comment: Recently test_exceptions was reporting random memory leaks. It seems that this was caused by the pickling part of testAttributes, which uses a random integer for pickling protocol. With this patch applied, I couldn't reproduce the leak anymore, although I didn't run it 666 times. The patch also includes a fix for the pickling part of the test (previously it was checking the attributes of the original exception, not the unpickled one), removes another unused import and moves all the imports to the top of the file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-07 03:00 Message: Logged In: YES user_id=31435 Woo hoo! This appears to cure the oddball "leaks" for me too, but no idea why. Outstanding anyway ;-) I fiddled the patch a bit to exercise both pickle and cPickle, and to use pickle.HIGHEST_PROTOCOL instead of the hardcoded 2. Checked in as revision 46705 on the trunk. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501987&group_id=5470 From noreply at sourceforge.net Thu Jun 8 06:30:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 21:30:57 -0700 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 Message generated for change (Settings changed) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) Assigned to: Gregory P. Smith (greg) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 15:07 Message: Logged In: YES user_id=1429720 Very nice .. yes using a bare exception causes the expected TypeError exception. I tried this in Python 2.4 and without any changes it correctly raises TypeError. I checked the differences between the 2.3 dbtables and 2.4 and there are no significant changes (i.e. the Modify catches the same exceptions) so it's got to be somewhere else. I've uploaded a simple test case that creates a database, does an Insert and then attempts the Modify with a string which corrupts the DB in Python 2.3. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-19 14:35 Message: Logged In: YES user_id=764593 Correct, the values in the dictionaries should be callables (usually a function) which take the old value and return the new. That said, the test case would still be useful, because (1) calling a string should raise a TypeError (2) making a mistake should not corrupt the database. Perhaps the first except clause (which triggers a rollback) needs to be a bare except? I'm guess the same is true of some of the other abort() lines... ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 10:11 Message: Logged In: YES user_id=1429720 I'm new to Python so this may be the problem, does the dbtables.Modify function require a function in the mappings. i.e. tdb.Modify('mytable', conditions= {'ID':dbtables.ExactCond('1')}, mappings={'ID':FUNCTION}) where the function returns the new value? (not mappings= {'ID':'newvalue'}) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Thu Jun 8 07:18:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Jun 2006 22:18:04 -0700 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: jross (j_ross) Assigned to: Gregory P. Smith (greg) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-07 22:18 Message: Logged In: YES user_id=413 fixed in SVN 46736 for python 2.5. honestly people should just use sqlite3 instead of dbtables. ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 15:07 Message: Logged In: YES user_id=1429720 Very nice .. yes using a bare exception causes the expected TypeError exception. I tried this in Python 2.4 and without any changes it correctly raises TypeError. I checked the differences between the 2.3 dbtables and 2.4 and there are no significant changes (i.e. the Modify catches the same exceptions) so it's got to be somewhere else. I've uploaded a simple test case that creates a database, does an Insert and then attempts the Modify with a string which corrupts the DB in Python 2.3. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-19 14:35 Message: Logged In: YES user_id=764593 Correct, the values in the dictionaries should be callables (usually a function) which take the old value and return the new. That said, the test case would still be useful, because (1) calling a string should raise a TypeError (2) making a mistake should not corrupt the database. Perhaps the first except clause (which triggers a rollback) needs to be a bare except? I'm guess the same is true of some of the other abort() lines... ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 10:11 Message: Logged In: YES user_id=1429720 I'm new to Python so this may be the problem, does the dbtables.Modify function require a function in the mappings. i.e. tdb.Modify('mytable', conditions= {'ID':dbtables.ExactCond('1')}, mappings={'ID':FUNCTION}) where the function returns the new value? (not mappings= {'ID':'newvalue'}) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Thu Jun 8 09:15:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 00:15:59 -0700 Subject: [Patches] [ python-Patches-1410680 ] Add 'surgical editing' to ConfigParser Message-ID: Patches item #1410680, was opened at 2006-01-20 06:12 Message generated for change (Comment added) made by geekmug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'surgical editing' to ConfigParser Initial Comment: See also: [ 1399309 ] ConfigParser to save with order [ 1371075 ] ConfigParser to accept a custom dict to allow ordering The attached patch adds a new method, update_file, to RawConfigParser. This method is similar to the existing write method, but preserves blank lines, comments, and ordering, as requested many times on python-dev and python-list. These are the three requirements that Guido specified in January 2005. IMO the attached patch is better than 1399309 because it includes all the functionality (passing a pointer to an empty file results in a sorted write() output), but is completely backwards compatible as write() is unchanged. The addition of preserving comments is also essential for many applications. IMO the attached patch is better than 1371075 because the latter really requires a custom class (e.g. the third party one suggested) in order to be useful. It also doesn't address the issue of preserving comments. The attached patch is essentially a tidied up version of the one included with SpamBayes (in the OptionClass.py module), which is used extensively within SpamBayes (and has been for several years). Also attached are additional unittests for the new method, and a documentation patch. Please let me know if there are recommended changes. This patch does not address any of the additional ConfigParser improvements that have been suggested at various times. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-08 03:15 Message: Logged In: YES user_id=383208 Before I lose track of the updated patches I made.. They can be found here: http://scottdial.com/python-dev/ConfigParser.diff http://scottdial.com/python-dev/test_cfgparser.diff The notes I emailed Tony were: * I have modified the OPTCRE matching to not just throw away the whitespace after a [=:]. Second, I have modified the opt.rstrip(), again so that the whitespace isn't just thrown away. A new variable padded_vi then appears which is a formatting-preserved version of vi. * I have removed at least one erroneous write('\n'), and changed the pattern for adding newlines to missing sections, such that the newlines are added /before/ the section heading (and only if there are lines appearing before). These together solve the growing blank lines phenomena. * I have modified the add_missing section to deal with DEFAULTSECT appropriately. Which solves the appearing/disappearing act that I had mentioned. * I have updated the test's to match the new expected output. --- And in reponse to Jim's comment, such a feature is not in the scope of the patch. The patch is to explicitly leave things the way they are, so any sort of sorting would make no sense. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 10:11 Message: Logged In: YES user_id=764593 Wanting to keep the whole thing (except defaultsection) in sorted order will probably be a common use case. It sounds like you can do this by "updating" to an empty file, but it isn't the obvious solution. Could you either add an option to sort the whole thing (so inserts may not be at the end) or an explicit mention in the docstring of how to get this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 From noreply at sourceforge.net Thu Jun 8 10:06:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 01:06:46 -0700 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 10:14 Message generated for change (Comment added) made by rockyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- >Comment By: Rocky Bernstein (rockyb) Date: 2006-06-08 04:06 Message: Logged In: YES user_id=158581 Sorry for not responding earlier. As getting this was taking a bit of time moving forward, in the interrum I had been making much faster progress by splitting this off into it's own little project under the bash debugger project I have on sourceforge (http://bashdb.sourceforge.net/pydb). Being able to make public releases earlier and oftener has offorded the oppertunity to move much further along much quicker than via the patch method (where we still haven't gotten past restarting the debugger). Now back to your comments/questions. In pydb, there are two kinds of "restart". "run" is like gdb's run. Debugger state (breakpoints, watchpoints, display expressions, debugger settings for list size, etc.) are preserved. Same as in gdb. Gdb does not to my knowledge have a command called "restart". However I've taken your suggestion of not having a "restart" be the same thing as "run". "restart" is a re-exec of the debugger. No state is save. As a debugger writer, I personally find that one useful ;-) Having the R be an alias for "run" is helpful since it's short and matches what's used Perl where people use the debugger more frequently. In fact there's a whole book written on the Perl debugger. (And I also use 'R' in the GNU Make and bash debuggers.) As for "ru", well, since I've added command completion, I feel this issue is less important. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 23:51 Message: Logged In: YES user_id=971153 one suggestion though: do we really need 'restart' alias? The main problem is that gdb uses "restart" for a very different purpose (restarting a program from a known state)..And we probably shouldn't deviate from gdb's command set unless we have to. Also I think we should not pollute the command space without a real need...(a similar argument could be made agaist "ru" abbreviation as well, but it's of lesser importance) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 23:40 Message: Logged In: YES user_id=971153 The patch works for me. I think the feature is desirable. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 16:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Thu Jun 8 14:11:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 05:11:17 -0700 Subject: [Patches] [ python-Patches-1500504 ] Alternate RFC 3986 compliant URI parsing module Message-ID: Patches item #1500504, was opened at 2006-06-05 00:50 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Alternate RFC 3986 compliant URI parsing module Initial Comment: Inspired by (and based on) Paul Jimenez's uriparse module (http://python.org/sf/1462525), urischemes tries to put a cleaner interface in front of the URI parsing engine. Most of the module works with a URI subclass of tuple that is always a 5-tuple (scheme, authority, path, query, fragment). The authority component is either None, or a URIAuthority subclass of tuple that is always a 4-tuple (user, password, host, port). The function make_uri will create a URI string from the 5 constituent components of a URI. The components do not need to be strings - if they are not strings, str() will be invoked on them (this allows the URIAuthority tuple subclass to be used transparently instead of a string for the authority component). The result is checked to ensure it is an RFC-compliant URI. The function split_uri accepts a string and returns a URI object with strings as the individual elements. Invoking str() on this object will recreate a URI string using make_uri(). The regex underlying this operation is now broken out and available as module level attributes like URI_PATTERN. The functions split_authority and make_authority are similar, only working solely on the authority component rather than the whole URI. The function parse_uri digs into the internal structure of a URI, also parsing the components. This will replace a non-empty URI authority component string with a URIAuthority tuple subclass. Depending on the scheme, it may also replace other components (e.g. for mailto links, the path is replaced with a (user, host) tuple subclass). The main parsing engine is still URIParser (much the same as Paul's), but the root of the internal parser hierarchy is now SchemeParser. This has two subclasses, URLParser and MailtoParser. The various URL flavours are now different instances of URLParser rather than subclasses. All of the actual parsers are available as module level attributes with the same name as the scheme they parse. Additionally, each parser knows the name of the scheme it is intended to parse. The parse() methods of the individual parsers are now expected to return a URI object (SchemeParser actually takes care of this). The parse() method also takes a dictionary of defaults, which can override the defaults supplied by the parser instance. The unparse() method is gone - instead, the scheme parser should ensure that all components returned are either strings or produce the right thing when __str__ is invoked (e.g. see _MailtoURIPath) The module level 'schemes' attribute is a mapping from scheme names to parsers that is automatically populated with all instances of SchemeParser that are found in the module globals() urljoin has been renamed to join_uri to match the style of the other names in the module. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-08 22:11 Message: Logged In: YES user_id=1038590 Uploaded version 0.4 This version cleans up the logic in resolve_uripath a bit (use a separate loop to strip the leading dot segments, add comments explaining meaning of if statements when dealing with dot segments). It also exposes EmailPath (along with split_emailpath and join_emailpath) as public objects, rather than treating them as internal to the MailtoSchemeParser. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-07 01:46 Message: Logged In: YES user_id=1038590 Uploaded version 0.3 which passes all the RFC tests, as well as the failing 4Suite tests Mike sent me based on version 0.1 and 0.2. The last 4suite failure went away when I realised those tests expected to operate in strict mode :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-05 23:53 Message: Logged In: YES user_id=1038590 Updated version attached which addresses some issues raised by Mike Brown in private mail (the difference between a URI and a URI reference and some major differences between URI paths and posix paths). Also settled on split/join for the component separation and recombination operations and made the join methods all take a tuple so that join_x(split_x(uri)) round trips. Based on the terminology in the RFC, the function to combine a URI reference with a base URI is now called "resolve_uriref". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500504&group_id=5470 From noreply at sourceforge.net Thu Jun 8 15:05:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 06:05:49 -0700 Subject: [Patches] [ python-Patches-1501979 ] syntax errors on continuation lines Message-ID: Patches item #1501979, was opened at 2006-06-07 02:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Miller (rcmiller) Assigned to: Nobody/Anonymous (nobody) Summary: syntax errors on continuation lines Initial Comment: This patch modifies syntax error location information to indicate when an error is detected on a statement continuation line, for example File "test.py", line 42 (continuing line 41) The intent is to be less confusing when an error reported on one line is actually the result of unbalanced brackets on a previous line. The change adds a new 'stmt_lineno' field to the SyntaxError exception, containing the line number on which the statement started. The patch is against r46701 and was developed and tested on Fedora 4 Linux. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 13:05 Message: Logged In: YES user_id=849994 Note that you cannot give a "|" inside a tuple specification in PyArg_ParseTuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501979&group_id=5470 From noreply at sourceforge.net Thu Jun 8 19:22:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 10:22:07 -0700 Subject: [Patches] [ python-Patches-1503046 ] Conditional compilation of zlib.(de)compressobj.copy Message-ID: Patches item #1503046, was opened at 2006-06-08 13: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=1503046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Conditional compilation of zlib.(de)compressobj.copy Initial Comment: First pass at a patch to only compile the new copy() methods for (de)compression objects in zlib if the zlib library supports them. I ran autoheader to pick up the AC_DEFINE from configure.in, and it looks like it changed pyconfig.h.in quite a bit. Probably the only part that needs to stay in is the #undef ZLIB_HAS_COPY part. If inflateCopy() is not found in the zlib library, then the copy() methods are not compiled. Lib/test_zlib.py has been updated to only test these methods if they exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 From noreply at sourceforge.net Thu Jun 8 19:46:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Jun 2006 10:46:54 -0700 Subject: [Patches] [ python-Patches-1503046 ] Conditional compilation of zlib.(de)compressobj.copy Message-ID: Patches item #1503046, was opened at 2006-06-08 19:22 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Chris AtLee (catlee) >Assigned to: Martin v. L??wis (loewis) Summary: Conditional compilation of zlib.(de)compressobj.copy Initial Comment: First pass at a patch to only compile the new copy() methods for (de)compression objects in zlib if the zlib library supports them. I ran autoheader to pick up the AC_DEFINE from configure.in, and it looks like it changed pyconfig.h.in quite a bit. Probably the only part that needs to stay in is the #undef ZLIB_HAS_COPY part. If inflateCopy() is not found in the zlib library, then the copy() methods are not compiled. Lib/test_zlib.py has been updated to only test these methods if they exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 From noreply at sourceforge.net Fri Jun 9 16:47:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 07:47:49 -0700 Subject: [Patches] [ python-Patches-1503556 ] Allow Empty Subscript List Without Parentheses Message-ID: Patches item #1503556, was opened at 2006-06-09 17: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=1503556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Empty Subscript List Without Parentheses Initial Comment: This is a reference implementation of PEP XXX, which makes writing "x[]" equivalent to writing "x[()]". It passes the Python test suite, but currently doesn't provide additional tests or documentation. The attached diff doesn't include changes to auto-generated files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503556&group_id=5470 From noreply at sourceforge.net Fri Jun 9 22:13:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 13:13:24 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-05-31 13:41 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 16:13 Message: Logged In: YES user_id=591932 The patch can be simplified by always calling PySequence_Tuple() and doing the decref instead of special casing tuples. If you pass PySequence_Tuple() a tuple it will incref it and hand it back to you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-05-31 21:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Fri Jun 9 22:42:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 13:42:23 -0700 Subject: [Patches] [ python-Patches-1503717 ] Tiny patch to stop make spam Message-ID: Patches item #1503717, was opened at 2006-06-09 16: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=1503717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Tiny patch to stop make spam Initial Comment: It's always bothered me that python's Makefile outputs: case $MAKEFLAGS in \ *-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 Maybe it does this for a good reason I don't know about :) In case there isn't, here's a one-line patch to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503717&group_id=5470 From noreply at sourceforge.net Fri Jun 9 22:44:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Jun 2006 13:44:44 -0700 Subject: [Patches] [ python-Patches-1503717 ] Tiny patch to stop make spam Message-ID: Patches item #1503717, was opened at 2006-06-09 20:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: Tiny patch to stop make spam Initial Comment: It's always bothered me that python's Makefile outputs: case $MAKEFLAGS in \ *-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 Maybe it does this for a good reason I don't know about :) In case there isn't, here's a one-line patch to fix it. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-09 20:44 Message: Logged In: YES user_id=849994 I'm very much for this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503717&group_id=5470 From noreply at sourceforge.net Sat Jun 10 04:20:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 9 Jun 2006 19:20:09 -0700 Subject: [Patches] [ python-Patches-1476578 ] Add help reference on Mac Message-ID: <200606100220.k5A2K9SY018934@sc8-sf-db2-new-b.sourceforge.net> Patches item #1476578, was opened at 04/25/06 18:21 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1476578&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Add help reference on Mac Initial Comment: On the Mac, you can't add a help reference in Configure IDLE by browsing because configHelpSourceEdit.py tries to assign into a specific entry in a tuple. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 06/09/06 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 05/26/06 06:10 Message: Logged In: YES user_id=580910 I've checked in a simular patch on the trunk and release24-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1476578&group_id=5470 From noreply at sourceforge.net Sat Jun 10 14:24:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 05:24:57 -0700 Subject: [Patches] [ python-Patches-1495999 ] Windows CE support (part 2) Message-ID: Patches item #1495999, was opened at 2006-05-27 16:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1495999&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Luke Dunstan (infidel) Assigned to: Nobody/Anonymous (nobody) Summary: Windows CE support (part 2) Initial Comment: This patch contains some more changes necessary to build Python trunk for Windows CE 4.x. More patches to come... The changes are: Missing headers: conio.h, direct.h, errno.h, io.h, process.h, signal.h, sys/stat.h, sys/types.h - Change #ifndef DONT_HAVE_*_H to HAVE_*_H - Add #ifdef guards for many of the #includes for these headers - Add checks for headers to configure.in, pyconfig.h.in - Add HAVE_*_H to manually edited versions of pyconfig.h (except for Windows CE) - NOTE: the following are Windows-specific headers: conio.h, direct.h, io.h, process.h PC/pyconfig.h: - define dummy macro implementations of getenv() and environ (Windows CE only) - define macro implementation of GetVersion() (Windows CE only) Modules/socketmodule.c: adjusted _MSC_VER conditional ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-10 14:24 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46719. HAVE_IO_H was duplicated, so I remove one occurrence. I also removed DONT_HAVE_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1495999&group_id=5470 From noreply at sourceforge.net Sat Jun 10 18:30:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 09:30:11 -0700 Subject: [Patches] [ python-Patches-1504046 ] Rough documentation for xml.etree.ElementTree Message-ID: Patches item #1504046, was opened at 2006-06-10 18:30 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=1504046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: Rough documentation for xml.etree.ElementTree Initial Comment: Here's a text version (based on the existing PythonDoc documentation). Feel free to grab it and convert it to Latex. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 From noreply at sourceforge.net Sat Jun 10 19:45:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 10:45:15 -0700 Subject: [Patches] [ python-Patches-1504073 ] Patch for 1496501 tarfile opener order Message-ID: Patches item #1504073, was opened at 2006-06-10 13:45 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=1504073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Diederich (jackdied) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for 1496501 tarfile opener order Initial Comment: when passing a fileobj into tarfile.open() without specifying the type open() will try openers in their dict key order from TarFile.OPEN_METH. This can fail if the order changes. This patch adds a tell() and seek() on failure of openers. fileobjs must already support these methods to work so this makes no new requirements. OpenOrderTest uses a dict-alike with shuffled keys to try and provoke the wrong orders for openers. Let me know if it looks good and I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504073&group_id=5470 From noreply at sourceforge.net Sat Jun 10 21:30:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 12:30:35 -0700 Subject: [Patches] [ python-Patches-1504046 ] Rough documentation for xml.etree.ElementTree Message-ID: Patches item #1504046, was opened at 2006-06-10 12:30 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: Rough documentation for xml.etree.ElementTree Initial Comment: Here's a text version (based on the existing PythonDoc documentation). Feel free to grab it and convert it to Latex. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 15:30 Message: Logged In: YES user_id=3066 There's an open question on whether this should be documented as xml.etree or xmlcore.etree. With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused "xml" package insanity any further. Posted also to python-dev: http://mail.python.org/pipermail/python-dev/2006-June/065816.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 From noreply at sourceforge.net Sat Jun 10 22:04:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 13:04:53 -0700 Subject: [Patches] [ python-Patches-1303595 ] Update documentation for __builtins__ Message-ID: Patches item #1303595, was opened at 2005-09-24 19:06 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1303595&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Update documentation for __builtins__ Initial Comment: If applied, this patch would explicitly tell users that they should be using __builtin__ to override built-in functions, rather than __builtins__. The patch would also add documentation clairifying that __builtins__ is a module when in __main__ and a dictionary anywhere else. This diff was made against dist/src/Doc/ref/ref4.tex, version 1.38 from CVS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 16:04 Message: Logged In: YES user_id=3066 Interestingly, your patch gets the sense which object is bound to __builtins__ in what context reversed. I've modified the patch a bit to correct that and make the warning about direct use of __builtins__ visually stronger (at least in the HTML format). Committed to the trunk as revision 46826, and to the Python 2.4.x maintenance branch as revision 46828. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1303595&group_id=5470 From noreply at sourceforge.net Sat Jun 10 22:20:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 13:20:02 -0700 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-22 20:15 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Nobody/Anonymous (nobody) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 16:20 Message: Logged In: YES user_id=3066 This should be handled by someone who knows something about the SSL API. I'm not at all sure why I assigned it to myself to begin with. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-08-31 14:27 Message: Logged In: YES user_id=21627 Sure, I agree the current documentation is wrong. It would be good to test the feature before correcting the documentation, though. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-31 14:09 Message: Logged In: YES user_id=261020 <Googles for x509> Ah. That appears to be true. In that case, do you agree that the following is still wrong (taken from urllib.URLOpener docs)? Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. You don't need either dict entry for opening most https: URLs. Also, it gives no clue that x509 is for client authentication, and that server authentication is not done. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-08-31 12:16 Message: Logged In: YES user_id=21627 Isn't the purpose of these arguments client-side authentication? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Sat Jun 10 22:21:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 13:21:12 -0700 Subject: [Patches] [ python-Patches-1216942 ] Suggested Additional Material for urllib2 docs Message-ID: Patches item #1216942, was opened at 2005-06-08 05:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Suggested Additional Material for urllib2 docs Initial Comment: This is some suggested additional material for the urllib2 docs. Particularly the part about error codes and the reason/code attributes of error objects is *missing* from the manual and needed. Also the example showing basic Authentication using password manager/handler/opener may help avoid some confusion. Alternatively you can link to my online tutorials at http://www.voidspace.org.uk/python/articles.shtml#http :-) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 16:21 Message: Logged In: YES user_id=3066 Closed as suggested. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-05-01 21:22 Message: Logged In: YES user_id=261020 Andrew Kuchling checked in Michael's tutorial as a howto, so I guess this can be closed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-22 17:07 Message: Logged In: YES user_id=261020 Just to shout it out again: no need for said patches to contain TeX markup!-) Plain text / reST pasted into the existing docs is ok (though making it clear by some means what is a heading and what isn't &c. is obviously desirable). I only want a patch because that would make it clear how the additions are intended to be integrated with the existing docs. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-22 17:01 Message: Logged In: YES user_id=261020 Fred, what will you TeXify? Are you waiting for Mike to reply, or were you saying that you'll TeXify what he already submitted? Personally, I'm not happy with the original as-is, foremost because it's not clear how it is intended to fit with the existing docs (there are certainly other problems with the suggested additions, but not much point going into detail before there's a patch). I would be happy to review / edit at least some of the content it if it were presented as patch(es). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-12-22 09:53 Message: Logged In: YES user_id=3066 I'll TeXify. I agree with John about reproducing the response code listing; that's a good place to simply defer to the HTTP spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:01 Message: Logged In: YES user_id=261020 I'm sure doc improvements are welcome here, so thank you :) However, I think you need to 1) split this up into small patches that address very specific issues, and briefly justify each change in the patch submission note on the SF patch tracker 2) present the patches by editing the original .tex source files from src/Doc/lib and then running 'diff -u' or 'svn diff' (it doesn't matter if you can't compile the docs or get the TeX markup wrong, just as long as everybody can see exactly what the intended changes to the text are) Also, one thing that caught my eye on a very brief scan was that the actual response code->name mapping (rather than a note to document the existence of that mapping) shouldn't be reproduced in the docs, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 From noreply at sourceforge.net Sun Jun 11 04:13:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Jun 2006 19:13:12 -0700 Subject: [Patches] [ python-Patches-1504199 ] Switch syntax (partial PEP 275) Message-ID: Patches item #1504199, was opened at 2006-06-11 12: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=1504199&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Switch syntax (partial PEP 275) Initial Comment: Attached is a partial implementation of PEP 275. It should offer a slight performance enhancement over if/elif/else, although it won't be nearly as fast as a lookup table generated at compile time (as the PEP suggests). However, it is more flexible than a compile-time generated lookup table in that it accepts expressions - not just constants - for each case clause. No new opcodes were added. Cheers, Tom ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504199&group_id=5470 From noreply at sourceforge.net Sun Jun 11 22:33:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 13:33:28 -0700 Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64 Message-ID: Patches item #1446489, was opened at 2006-03-09 06:58 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: zipfile: support for ZIP64 Initial Comment: The attached patch implements support for ZIP64, that is zipfiles containing very large (>4GByte) files and zipfiles that are larger than 4GByte themselves. The output of this patch can be read by pkzip (see below for the actual version I used for testing). ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-06-11 13:33 Message: Logged In: YES user_id=413 reading zipfile64-version64.patch: * why does the zipfile module import itself? * Why is the default ZIP64 limit 1 << 30? shouldn't that be 1 << 31 - 1 (or slightly less) for maximum compatibility on existing <2GiB zip files or zips with data just under 2GiB. Don't force zip64's use unless the size actually exceeds a 32bit signed integer. * assert diskno == 0 and assert nodisks == 1 should be turned into BadZipFile exceptions with an explanation that multi-disk zip files aren't supported. * in main() document the -t option in the usage string. * TestZip64InSmallFiles changes zipfile.ZIP64_LIMIT but will not restore the value if a test fails (that could lead to other unrelated test failures). not a problem in the hopefully normal case of all tests passing. use a try: finally: to make sure that gets reset. * documentation: "Is does optionally handle" is awkward. how about "It can handle" The removal of the file_offset attribute makes sense but does make me wonder how much existing code that could break. I suggest leaving file_offset out and if any python 2.5 beta tester complains, restoring it or making scanning to look file offsets up a ZipFile option (defaulting to True). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-30 06:28 Message: Logged In: YES user_id=580910 I've added some more tests for pre-existing functionality. The unittests are still far from comprehensive, but at least touch upon most functionality of zipfile. Does anyone feel like reviewing this? I'd like to get this into python2.5. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 01:26 Message: Logged In: YES user_id=580910 I've attached yet another version, this version reintroduces some functionalitity that was unintentionally removed and fixes a lame bug that caused test_zipimport to fail. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 06:10 Message: Logged In: YES user_id=580910 I've found some time to work on this. I've added zipfile-zip64- version2.patch, this version: * Makes zip64 behaviour optional (defaults to off because zip(1) doesn't support zip64) * Is significantly faster for large zipfiles because it doesn't scan the entire zipfile just to check that the file headers are consistent with the central directory w.r.t. filename (this check is now done when trying to read a file) * Updates the reference documentation. * Adds unittests. There are two sets of tests: one set tests the behaviour of zip64 extensions using small files by lowering the zip64 cutoff point and is run every time, the other set do tests with huge zipfiles and are run when the largefile feature is enabled when running the tests. There one backward incompatible change: ZipInfo objects no longer have a file_offset attribute. That was the other reason for scanning the entire zipfile when opening it. IMNSHO this should have been a private attribute and the cost of this feature is not worth its *very* limited usefulness. As an indication of its cost: I got a 6x speedup when I removed the calculation of the file_offset attribute, something that adds up when you are dealing with huge zipfiles (I wrote this patch because I'm dealing with 10+GByte zipfiles with tens of thousands of files at work). I noticed that zipfile raises RuntimeError in some places. I've changed one of those to zipfile.BadZipfile, but others remain. I don't like this, most of them should be replaced by TypeError or ValueError exceptions. BTW. This patch also supports storing files >4GByte in the zipfile, but that feature isn't very useful because zipfile doesn't have an API for reading file data incrementally. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-16 00:55 Message: Logged In: YES user_id=580910 I haven't had time to work on this, all time I had to work on python related stuff has been eaten by finishing PyObjC's port to intel macs and universal binary patches. The former is now done, the latter almost so I'll have some time to work on this again especially because I'm using this patch at work and might be able to claim some time to work on this during work-hours. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-16 00:41 Message: Logged In: YES user_id=849994 Since 2.5 beta is coming close, have you made progress on the tests/docs? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 12:13 Message: Logged In: YES user_id=580910 The "don't use the ZIP64 extension" flag is a good idea, zipfiles that use this extension aren't readable by the infozip tools (zip and unzip on most unix systems). I'll add tests and documentation in the near future. The version of zipfile that I'm currently using also contains a patch for speeding up the opening of zipfiles, for the type of files I'm dealing with (about 11GByte large with tens of thousands of files) the speedup is very significant. I suppose it's better to file that as a separate patch after this has been approved. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-01 21:02 Message: Logged In: YES user_id=29957 I'd like to see a testcase and possibly a note for the documentation about the new semantics. Also, should it be possible to say "don't use the ZIP64 extension, instead raise an Error" for people who don't want to generate these? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-09 07:28 Message: Logged In: YES user_id=580910 Oops, I've uploaded the wrong file. zipfile-zip64.patch is the correct one. I've tested the correctness of created archives using this version of pkzip: pkzipc -version PKZIP(R) Server Version 8 ZIP Compression Utility for Linux X86 Copyright (C) 1989-2005 PKWARE, Inc. All Rights Reserved. Evaluation Version PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 Patent Pending Version 8.40.66 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 From noreply at sourceforge.net Sun Jun 11 23:09:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 14:09:40 -0700 Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64 Message-ID: Patches item #1446489, was opened at 2006-03-09 15:58 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: zipfile: support for ZIP64 Initial Comment: The attached patch implements support for ZIP64, that is zipfiles containing very large (>4GByte) files and zipfiles that are larger than 4GByte themselves. The output of this patch can be read by pkzip (see below for the actual version I used for testing). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-11 23:09 Message: Logged In: YES user_id=580910 * The import of zipfile itself is a bug * The limit should indead be raised to (1<<31-1). * the diskno and nodisks assertions are present in the current version of zipfiles, but I agree that those should be changed into exceptions. * I've updated main to document and actually allow the -t option * TestZip64InSmallFiles restores the ZIP64_LIMIT in the tearDown method, isn't that good enough? I sure hope that nobody actually uses the file_offset. The only usecase I can think of for that is to reimplement the read method. If it turns out that this change does break existing code we could add yet another option, but lets wait with that until someone actually complains. I've uploaded a new version of the patch that fixes all these issues. BTW. Thanks for the review. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-06-11 22:33 Message: Logged In: YES user_id=413 reading zipfile64-version64.patch: * why does the zipfile module import itself? * Why is the default ZIP64 limit 1 << 30? shouldn't that be 1 << 31 - 1 (or slightly less) for maximum compatibility on existing <2GiB zip files or zips with data just under 2GiB. Don't force zip64's use unless the size actually exceeds a 32bit signed integer. * assert diskno == 0 and assert nodisks == 1 should be turned into BadZipFile exceptions with an explanation that multi-disk zip files aren't supported. * in main() document the -t option in the usage string. * TestZip64InSmallFiles changes zipfile.ZIP64_LIMIT but will not restore the value if a test fails (that could lead to other unrelated test failures). not a problem in the hopefully normal case of all tests passing. use a try: finally: to make sure that gets reset. * documentation: "Is does optionally handle" is awkward. how about "It can handle" The removal of the file_offset attribute makes sense but does make me wonder how much existing code that could break. I suggest leaving file_offset out and if any python 2.5 beta tester complains, restoring it or making scanning to look file offsets up a ZipFile option (defaulting to True). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-30 15:28 Message: Logged In: YES user_id=580910 I've added some more tests for pre-existing functionality. The unittests are still far from comprehensive, but at least touch upon most functionality of zipfile. Does anyone feel like reviewing this? I'd like to get this into python2.5. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 10:26 Message: Logged In: YES user_id=580910 I've attached yet another version, this version reintroduces some functionalitity that was unintentionally removed and fixes a lame bug that caused test_zipimport to fail. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 15:10 Message: Logged In: YES user_id=580910 I've found some time to work on this. I've added zipfile-zip64- version2.patch, this version: * Makes zip64 behaviour optional (defaults to off because zip(1) doesn't support zip64) * Is significantly faster for large zipfiles because it doesn't scan the entire zipfile just to check that the file headers are consistent with the central directory w.r.t. filename (this check is now done when trying to read a file) * Updates the reference documentation. * Adds unittests. There are two sets of tests: one set tests the behaviour of zip64 extensions using small files by lowering the zip64 cutoff point and is run every time, the other set do tests with huge zipfiles and are run when the largefile feature is enabled when running the tests. There one backward incompatible change: ZipInfo objects no longer have a file_offset attribute. That was the other reason for scanning the entire zipfile when opening it. IMNSHO this should have been a private attribute and the cost of this feature is not worth its *very* limited usefulness. As an indication of its cost: I got a 6x speedup when I removed the calculation of the file_offset attribute, something that adds up when you are dealing with huge zipfiles (I wrote this patch because I'm dealing with 10+GByte zipfiles with tens of thousands of files at work). I noticed that zipfile raises RuntimeError in some places. I've changed one of those to zipfile.BadZipfile, but others remain. I don't like this, most of them should be replaced by TypeError or ValueError exceptions. BTW. This patch also supports storing files >4GByte in the zipfile, but that feature isn't very useful because zipfile doesn't have an API for reading file data incrementally. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-16 09:55 Message: Logged In: YES user_id=580910 I haven't had time to work on this, all time I had to work on python related stuff has been eaten by finishing PyObjC's port to intel macs and universal binary patches. The former is now done, the latter almost so I'll have some time to work on this again especially because I'm using this patch at work and might be able to claim some time to work on this during work-hours. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-16 09:41 Message: Logged In: YES user_id=849994 Since 2.5 beta is coming close, have you made progress on the tests/docs? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:13 Message: Logged In: YES user_id=580910 The "don't use the ZIP64 extension" flag is a good idea, zipfiles that use this extension aren't readable by the infozip tools (zip and unzip on most unix systems). I'll add tests and documentation in the near future. The version of zipfile that I'm currently using also contains a patch for speeding up the opening of zipfiles, for the type of files I'm dealing with (about 11GByte large with tens of thousands of files) the speedup is very significant. I suppose it's better to file that as a separate patch after this has been approved. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-02 07:02 Message: Logged In: YES user_id=29957 I'd like to see a testcase and possibly a note for the documentation about the new semantics. Also, should it be possible to say "don't use the ZIP64 extension, instead raise an Error" for people who don't want to generate these? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-09 16:28 Message: Logged In: YES user_id=580910 Oops, I've uploaded the wrong file. zipfile-zip64.patch is the correct one. I've tested the correctness of created archives using this version of pkzip: pkzipc -version PKZIP(R) Server Version 8 ZIP Compression Utility for Linux X86 Copyright (C) 1989-2005 PKWARE, Inc. All Rights Reserved. Evaluation Version PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 Patent Pending Version 8.40.66 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 From noreply at sourceforge.net Mon Jun 12 05:34:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 20:34:31 -0700 Subject: [Patches] [ python-Patches-1503046 ] Conditional compilation of zlib.(de)compressobj.copy Message-ID: Patches item #1503046, was opened at 2006-06-08 10:22 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Chris AtLee (catlee) >Assigned to: Neal Norwitz (nnorwitz) Summary: Conditional compilation of zlib.(de)compressobj.copy Initial Comment: First pass at a patch to only compile the new copy() methods for (de)compression objects in zlib if the zlib library supports them. I ran autoheader to pick up the AC_DEFINE from configure.in, and it looks like it changed pyconfig.h.in quite a bit. Probably the only part that needs to stay in is the #undef ZLIB_HAS_COPY part. If inflateCopy() is not found in the zlib library, then the copy() methods are not compiled. Lib/test_zlib.py has been updated to only test these methods if they exist. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-11 20:34 Message: Logged In: YES user_id=33168 Thanks! I changed ZLIB_HAS_COPY to HAVE_ZLIB_COPY to be more consistent with the rest of pyconfig.h.in. Committed revision 46886. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 From noreply at sourceforge.net Mon Jun 12 05:36:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Jun 2006 20:36:05 -0700 Subject: [Patches] [ python-Patches-1503046 ] Conditional compilation of zlib.(de)compressobj.copy Message-ID: Patches item #1503046, was opened at 2006-06-08 10:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Closed Resolution: Accepted Priority: 7 Submitted By: Chris AtLee (catlee) Assigned to: Neal Norwitz (nnorwitz) Summary: Conditional compilation of zlib.(de)compressobj.copy Initial Comment: First pass at a patch to only compile the new copy() methods for (de)compression objects in zlib if the zlib library supports them. I ran autoheader to pick up the AC_DEFINE from configure.in, and it looks like it changed pyconfig.h.in quite a bit. Probably the only part that needs to stay in is the #undef ZLIB_HAS_COPY part. If inflateCopy() is not found in the zlib library, then the copy() methods are not compiled. Lib/test_zlib.py has been updated to only test these methods if they exist. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-11 20:36 Message: Logged In: YES user_id=33168 Thanks! I changed ZLIB_HAS_COPY to HAVE_ZLIB_COPY to be more consistent with the rest of pyconfig.h.in. Committed revision 46886. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-11 20:34 Message: Logged In: YES user_id=33168 Thanks! I changed ZLIB_HAS_COPY to HAVE_ZLIB_COPY to be more consistent with the rest of pyconfig.h.in. Committed revision 46886. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503046&group_id=5470 From noreply at sourceforge.net Tue Jun 13 10:57:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 01:57:18 -0700 Subject: [Patches] [ python-Patches-1505257 ] winerror module Message-ID: Patches item #1505257, was opened at 2006-06-13 10: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=1505257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Martin v. L??wis (loewis) Summary: winerror module Initial Comment: Hi Martin, unfortunately I haven't found time to work on a C based winerror module. Here's a generator and the generated Python module which defines the interface. This can then later be replaced by a more efficient C implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 From noreply at sourceforge.net Tue Jun 13 14:09:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 05:09:13 -0700 Subject: [Patches] [ python-Patches-731328 ] AssertionError when building rpm under RedHat 9.1 Message-ID: Patches item #731328, was opened at 2003-05-02 12:56 Message generated for change (Settings changed) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ricardo Niederberger Cabral (niederberger) Assigned to: Sean Reifschneider (jafo) Summary: AssertionError when building rpm under RedHat 9.1 Initial Comment: When trying to build an rpm on RH 9: >From distutils __version__ = "1.0.3": File "distutils/command/bdist_rpm.py", line 316, in run assert len(rpms) == 1, \ AssertionError: unexpected number of RPM files found: ['build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-0.7-1.i386.rpm', 'build/bdist. linux-i686/rpm/RPMS/i386/imgSeek-debuginfo-0.7-1.i386.rpm'] I had to remove the assert statement on bdist_rpm.py:316 in order to build my rpm since rpmbuild from RH always seems to generate this extra -debuginfo rpm. So attached is a patch (cvs rev 1.37) to simply copy all generated RPM's to the dist/ directory. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2006-06-13 12:09 Message: Logged In: YES user_id=81797 No activity on this in the last several weeks. This is fixed in newer Fedora releases, and Red Hat 9.1 is no longer supported by Legacy projects. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2006-05-22 08:52 Message: Logged In: YES user_id=81797 Is 1.0.3 from the Red Hat RPMs, the python.org RPMs (which version), or directly downloaded from the distutils? If this is an issue in Distutils, I'd be interested in still fixing it. However, there hasn't been any activity on this in 3 years, so I'm planning on closing this unless I hear something further over, say, the next few weeks. Red Hat 9.1 is extremely legacy now, of course. Not at all supported for errata by either Red Hat or the other Legacy sites, so I'm inclined to feel the same. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-03-03 14:36 Message: Logged In: YES user_id=1188172 Does anyone still care about this issue? Or, other way round, does anything speak against applying and so copying all RPMs? ---------------------------------------------------------------------- Comment By: Ricardo Niederberger Cabral (niederberger) Date: 2003-05-28 01:59 Message: Logged In: YES user_id=354686 Sorry for not replying faster and providing more info. SF tracker didn't email me about your comment, and I don't have the RH system at hand right now. Anyway, it generates: foo-version.i386.rpm foo-version.src.rpm foo-debuginfo-version.i386.rpm instead of only the binary and src rpm's I would get on Mandrake 9 for example, which is what bdist_rpm.py currently expects. I don't know exactly what goes inside this debug-info rpm, but i guess it's probably the binary one compiled with debug symbols on. I can provide more info if necessary in a few days. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-05-03 11:01 Message: Logged In: YES user_id=21627 Can you provide more information? What rpm gets generated, and what files does it contain? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731328&group_id=5470 From noreply at sourceforge.net Wed Jun 14 04:05:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 19:05:21 -0700 Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime tunable Message-ID: Patches item #1454481, was opened at 2006-03-20 23:37 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Pending >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Make thread stack size runtime tunable Initial Comment: Platform default thread stack sizes vary considerably. Some are very generous (Win32: usually 1MB; Linux: 1MB, sometimes 8MB). Others are not (FreeBSD: 64k). Some platforms have restricted virtual address space OS/2: 512M less overhead) which makes hard coding a generous default thread stack size problematic. Some platforms thread commit stack address space, even though the memory backing it may not be committed (Windows, OS/2 at least). Some applications have a thirst for stack space in threads (Zope). Some programmers want to be able to use lots of threads, even in the face of sound advice about the lack of wisdom in this approach. The current approach to stack space management in threads in Python uses a hard coded strategy, relying on the platform having a useful default or relying on the system administrator or distribution builder over-riding the default at compile time. This patch is intended to allow developers some control over managing this resource from within Python code by way of a function in the thread module. As written, it is not intended to provide unlimited flexibility; that would probably require exposing the underlying mechanism as an option on the creation of each thread. An alternative approach to providing the functionality would be to use an environment variable to provide the information to the thread module. This has its pros and cons, in terms of flexibility and ease of use, and could be complementary to the approach implemented. The patch has been tested on OS/2 and FreeBSD 4.8. I have no means of testing the code on Win32 or Linux, though Linux is a pthread environment as is FreeBSD. Code base is SVN head from a few hours ago. A doc update is included. While I would like to see this functionality in Python 2.5, it is not a critical issue. Critique of the approach and implementation welcome. Something not addressed is the issue of tests, primarily because I haven't been able to think of a viable testing strategy - I'm all ears to suggestions for this. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-06-14 12:05 Message: Logged In: YES user_id=250749 Checked in to trunk after further revision in r46919, with minor test tweaks in r46925 & r46929. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-05-26 00:47 Message: Logged In: YES user_id=250749 Ok, v3 includes the additions to the threading module, tests in both test_thread and test_threading and docs in both thread and threading modules (duplicated as I don't know how to do the LaTex linking). If there are no other issues needing to be addressed, I propose to check these changes in sometime on the weekend of June 3-4 or thereabouts to get in a bit before the beta release. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-24 06:25 Message: Logged In: YES user_id=31435 Right, this one: "a simple shadow of the function as a module level function". If it affects all threads (which it does), then a module function is a natural place for it. If I a saw a method on the Thread class, the most natural (to me ;-)) assumption is that a_thread.stack_size(N) would set the stack size for the specific thread `a_thread`, but not affect other threads. Part of what makes that "the most natural" assumption is that Thread has no class or static methods today. As a module-level function, no such confusion is sanely possible. Sticking "stack_size" in threading.__all__, and adding from thread import stack_size to threading.py is all I'm looking for here. Well, plus docs and a test case ;-) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-23 15:35 Message: Logged In: YES user_id=250749 Thanks Tim. My default action is to try and match the prevailing style, but cut'n'paste propagated the flaw. thread_pthread.h was clean AFAICS, so I'll do a style normalisation (as a separate checkin) on thread_nt.py and thread_os2.h when commit time comes. As an "implementation detail", I hadn't considered that exposing it via threading was appropriate. I can see 2 approaches: - a simple shadow of the function as a module level function; or - a classmethod of the Thread class. Any hints on which would be the more preferable or natural approach? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-22 15:46 Message: Logged In: YES user_id=31435 The patch applies cleanly on WinXP, "and works" (I checked this by setting various stack sizes, spawning a thread doing nothing but a raw_input(), and looking at the VM size under Task Manager while the thread was paused waiting for input -- the VM size went up each time roughly by the stack-size increase; finally set stack_size to 0 again, and all the "extra" VM went away). Note that Python C style for defining functions puts the function name in the first column. For example, """ static int _pythread_nt_set_stacksize(size_t size) """ instead of """ static int _pythread_nt_set_stacksize(size_t size) """ The patch isn't consistent about this, and perhaps it's errenously ;-) aping bad style in surrounding function definitions. This should really be exposed via threading.py. `thread` is increasingly "just an implementation detail" of `threading`, and it actually felt weird to me to write a test program that had to import `thread`. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-14 22:51 Message: Logged In: YES user_id=250749 I have updated the patch along the lines Martin suggested. I have omitted OS/2 from the list of supported platforms in the doc patch as I haven't added OS/2 to anywhere else in the docs. My thinging has been that OS/2 is a 2nd tier platform, and I have kept an extensive port README file in the build directory (PC/os2emx) documenting port specific behaviour. The idea with the environment variable version was that it would be less "intrusive" a change from the user POV. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-11 01:09 Message: Logged In: YES user_id=21627 re 1) Currently, the usage of the stacksize attribute is depending on the definition of a THREAD_STACK_SIZE macro. I don't know where that comes from, but I guess whoever defines it knows what he is doing, so that the stacksize attribute is defined on such a system. re 2) I can accept that Python enforces a minimum above PTHREAD_STACK_MIN; it shouldn't be possible to set the stack size below PTHREAD_STACK_MIN, since that *will* fail when a thread is created. -1 for an environment variable version. What problem would that solve? If this patch gets implemented, applications can define their own environment variables if they think it helps, and users/admins can put something in sitecustomize.py if they think there should be an environment variable controlling the stack size for all Python applications on the system. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-04-11 00:45 Message: Logged In: YES user_id=250749 1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that (though I note its absence from the existing code...) 2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly inadequate for Python (my impression is that 20-32k is a fairly safe minimum for Python). In principle I don't have a problem with relying on PTHREAD_STACK_MIN, except for trying to play it safe. Any further thoughts on this? I'm also putting together an environment variable only version of the patch, with a view to getting that in first, and reworking this patch to work on top of that. Thanks for the comments. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-10 23:41 Message: Logged In: YES user_id=21627 Usage of pthread_attr_setstacksize should be conditional on the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to POSIX. Errors from pthread_attr_setstacksize should be reported (POSIX lists EINVAL as a possible error). I think PTHREAD_STACK_MIN should be considered. The documentation should list availibility of the feature, currently Win32, OS/2, and POSIX threads (with the TSS option, to be precise). If some platforms have specific additional requirements on the possible values (eg. must be a multiple of the page size), these should be documented, as well. Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-03-22 19:28 Message: Logged In: YES user_id=250749 Thanks for the comments. As implemented, the function is both a getter and (optionally) a setter which makes attempting to use a "get"/"set" prefix awkward. I chose this approach to make it a little simpler to support temporary changes. I did consider using a module attribute/variable, but it is slightly more unwieldy for this case: old_size = thread.stack_size(new_size) ... thread.stack_size(old_size) vs old_size = thread.stack_size thread.stack_size = new_size ... thread.stack_size = old_size or (using get/set accessors) old_size = thread.get_stacksize() thread.set_stacksize(new_size) ... thread.set_stacksize(old_size) I think an argument can be made for passing on the "get"/"set" naming consistency based on the guidelines in PEP 8. While I have a preference for what I've implemented, I'm more interested in getting the functionality in than debating its decor. If there's a strong view about these issues, I'm prepared to revise the patch accordingly. I don't believe that the functionality belongs anywhere else than the thread module, except possibly shadowing it in the threading module, as it is highly specific to thread support. The sys module seems more appropriate for general knobs, and only for specific knobs when there is no other choice IMO. Doing it outside the thread module also complicates the implementation, which I was trying to keep as simple as I could. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-21 00:58 Message: Logged In: YES user_id=55188 I'm all for this! The FreeBSD port have maintained a local patch to bump THREAD_STACK_SIZE. The patch will lighten FreeBSD users' burden around thread stack size. BTW, the naming, "thread.stack_size" seems to miss a verb while all the other functions on the thread module have it. How about set_stack_size() or set_stacksize()? Or, how about in sys module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 From noreply at sourceforge.net Wed Jun 14 07:15:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 22:15:20 -0700 Subject: [Patches] [ python-Patches-1505257 ] winerror module Message-ID: Patches item #1505257, was opened at 2006-06-13 10:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Martin v. L??wis (loewis) Summary: winerror module Initial Comment: Hi Martin, unfortunately I haven't found time to work on a C based winerror module. Here's a generator and the generated Python module which defines the interface. This can then later be replaced by a more efficient C implementation. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-14 07:15 Message: Logged In: YES user_id=21627 As discussed before, I am uncomfortable with a lookup object, instead of just two dicts or dict-like objects: it's inconsistent with the errno module, and I don't see the need for it. Also, can you please provide documentation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 From noreply at sourceforge.net Wed Jun 14 07:21:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 22:21:50 -0700 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 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=1455898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for mbcs codecs Initial Comment: Hello. I have noticed mbcs codecs sometimes generates broken string. I'm using Windows(Japanese) so mbcs is mapped to cp932 (close to shift_jis) When I run the attached script "a.zip", the entry "Error 00007"'s message becomes broken like attached file "b.txt". I think this happens because the string passed to PyUnicode_DecodeMBCS() sometimes terminates with leading byte, and MultiByteToWideChar() counts it for size of result string.buffer size. I hope attached patch "mbcs.patch" may fix the problem. It would be nice if this bug will be fixed in 2.4.3... Thank you. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-14 07:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46945. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:40 Message: Logged In: YES user_id=1200846 I reverted PyUnicode_Resize() patch for now, and recreated the patch as "mbcs.patch". >You should probably find someone on python-dev with a >multibyte version of Windows to look at the patch. OK, I will. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:18 Message: Logged In: YES user_id=1200846 >The change to PyUnicode_Resize() should be reverted (or done >in a way that doesn't lead to bugs). Sorry, how about this? Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 46417) +++ Objects/unicodeobject.c (working copy) @@ -326,7 +326,7 @@ return -1; } v = (PyUnicodeObject *)*unicode; - if (v == NULL || !PyUnicode_Check(v) || v->ob_refcnt != 1 || length < 0) { + if (v == NULL || !PyUnicode_Check(v) || length < 0) { PyErr_BadInternalCall(); return -1; } @@ -335,7 +335,7 @@ possible since these are being shared. We simply return a fresh copy with the same Unicode content. */ if (v->length != length && - (v == unicode_empty || v->length == 1)) { + (v == unicode_empty || v->length == 1 || v->ob_refcnt != 1)) { PyUnicodeObject *w = _PyUnicode_New(length); if (w == NULL) return -1; ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-05-26 17:43 Message: Logged In: YES user_id=89016 The change to PyUnicode_Resize() should be reverted (or done in a way that doesn't lead to bugs). Unfortunately I don't have a Windows where I can test the patch, so I'm unassigning the bug. You should probably find someone on python-dev with a multibyte version of Windows to look at the patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:06 Message: Logged In: YES user_id=1200846 >PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, >but probably I'll fix it too. Done. Attached as "mbcs_win64_support.patch". Now, total summary... - MBCS decoder and encoder now supports 64bit Py_ssize_t environment. (I don't have such machine, but I checked routine by defining NEED_RETRY and redefining INT_MAX as 2, 3, 4) - Fixed a bug of MBCS incremental decoder which was originaly reported by me. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-24 22:18 Message: Logged In: YES user_id=1200846 I updated the patch. - PyUnicode_DecodeMBCS now supports size >= INT_MAX. (I don't have machine to test such big string, but I have tested this routine replaced INT_MAX with 2 and 3) PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, but probably I'll fix it too. This patch includes Patch#1494487. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-02 13:40 Message: Logged In: YES user_id=1200846 I updated the patch. (I copy and pasted "int final = 0" from above code (ex: utf_16_ex_decode), maybe they also should be changed for consistency?) And one more thing, I noticed "errors" is ignored now. We can detect invalid character if we set MB_ERR_INVALID_CHARS flag when calling MultiByteToWideChar, but we cannot tell where is the position of invalid character, and MSDN saids this flag is available Win2000SP4 or later (I don't know why) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp So I didn't make the patch for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-25 19:22 Message: Logged In: YES user_id=89016 I think the default value for final in mbcs_decode() should be true, so that the stateless decoder detects incomplete byte sequences too. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-04-07 11:10 Message: Logged In: YES user_id=1200846 I have sent contributor form via postal mail. Probably you can get it after 10 days. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 10:16 Message: Logged In: YES user_id=1200846 You are right. I've updated the patch. (mbcs5.patch) >>> import codecs [20198 refs] >>> d = codecs.getincrementaldecoder("mbcs")() [20198 refs] >>> d.decode('\x82\xa0\x82') u'\u3042' [20198 refs] >>> d.decode('') u'' [20198 refs] >>> d.decode('', final=True) u'\x00' [20198 refs] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-27 18:06 Message: Logged In: YES user_id=89016 _buffer_decode() in the IncrementalDecoder ignores the final argument. IncrementalDecoder._buffer_decode() should pass on its final argument to _codecsmodules.c::mbcs_decode(), which should be extended to accept the final argument. Also PyUnicode_DecodeMBCSStateful() must handle consumed == NULL correctly (with your patch it drops trailing lead bytes even if consumed == NULL) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 09:41 Message: Logged In: YES user_id=1200846 I replaced tests. Probably this is better instead of comparing the two string generated by same decoder. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 07:44 Message: Logged In: YES user_id=1200846 My real name is Hirokazu Yamamoto. But sorry, I don't have FAX. (It's needed to send contributor form, isn't it?) I'll attach the patch updated for trunk. And I'll attach the tests. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-26 23:05 Message: Logged In: YES user_id=21627 I have reservations against this patch because of the quasi-anonymous nature of the submission. ocean-city, can you please state your real name? Would you also be willing to fill out a contributor form, as shown on http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-24 15:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-23 22:44 Message: Logged In: YES user_id=89016 This isn't a bugfix in the strictest sense, so IMHO this patch shouldn't go into 2.4. If the patch goes into 2.5, it would need the appropriate changes to encodings/mbcs.py (i.e. the IncrementalDecoder would have to be changed (inheriting from BufferedIncrementalDecoder). I realize that this patch might be hard to test, as results are dependent on locale. Nevertheless at least some tests would be good (even if they are only run or do something useful on a certain locale and are skipped otherwise). ocean-city, can you update the patch for the trunk and add tests? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-23 03:51 Message: Logged In: YES user_id=1200846 Hello. This is my final patch. (mbcs4.patch) - mbcs3a.patch: _mbsbtype depends on locale not system ANSI code page. so probably it's not good to use it with MultiByteToWideChar. - mbcs3b.patch: CharNext may cause buffer overflow. and this patch always calls CharPrev but it's not needed if string is not terminated with "potensial" lead byte. I hope this is stable enough to commit on repositry. Thank you. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 15:36 Message: Logged In: YES user_id=1200846 Sorry, I was stupid. MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp) saids, > IsDBCSLeadByte can only indicate a potential lead byte value. IsDBCSLeadByte was returning 1 for some trail byte (ex: "???"[1]) The patch "mbcs3a.patch" worked for me, but _mbsbtype is probably compiler specific. Is that OK? The patch "mbcs3b.patch" also worked for me and it only uses Win32API, but I don't have enough faith on this implementation... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:31 Message: Logged In: YES user_id=1200846 Sorry, I found problem when tried more long text file... Please wait. I'll investigate more intensibly. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:13 Message: Logged In: YES user_id=1200846 Thank you for reply. How about this? (I'm a newbie, I hope this is right tex format but... can you confirm this? I created this patch by copy & paste from PyUnicode_DecodeUTF16Stateful and some modification) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:12 Message: Logged In: YES user_id=38388 One more nit: the doc patch is missing. Please add a patch for the API docs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:11 Message: Logged In: YES user_id=38388 As I understand your comment, the mbcs codec will have a problem if the input string terminates with a lead byte. Could you add a comment regarding this to the patch ?! I can't test the patch, since I don't have a Japanese Windows to check on, but from looking at the patch, it seems OK. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 08:42 Message: Logged In: YES user_id=1200846 I forgot to mention this. "mbcs.patch" is for release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Jun 14 08:09:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Jun 2006 23:09:42 -0700 Subject: [Patches] [ python-Patches-1501534 ] Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Message-ID: Patches item #1501534, was opened at 2006-06-06 10:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeung Mun Sic (ruseel) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Bug #1339007 - shelve.open('non-existant-file', 'r') Initial Comment: Fix Bug #1339007 I think that Bug #1339007 is making confusion in many places. http://www.google.com/search? hl=ko&newwindow=1&q=dbfilenameshelf+attributeerror&lr= lang_en%7Clang_ko http://mail.python.org/pipermail/python-list/2003- October/188138.html In my case, I ran into this bug with py-wordnet. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 06:09 Message: Logged In: YES user_id=849994 Thanks for the patch, fixed in rev. 46946, 46947 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501534&group_id=5470 From noreply at sourceforge.net Thu Jun 15 01:46:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Jun 2006 16:46:52 -0700 Subject: [Patches] [ python-Patches-1494750 ] BaseWidget.destroy updates master's childern too early Message-ID: Patches item #1494750, was opened at 2006-05-24 23:03 Message generated for change (Settings changed) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494750&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L??wis (loewis) Summary: BaseWidget.destroy updates master's childern too early Initial Comment: In BaseWidget.destroy(), it removes self from its master's dict of children before it calls the Tcl destroy on the widget. If the widget has a destroy callback (like Togl, the Tk OpenGL widget), then nametowidget throws an exception when given the widget's name even though the Python widget still exists. Just reordering the code, so that the Tcl destroy happens before the updating of the master's dict of children, fixes the problem. The bug is present in earlier versions of Tkinter too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494750&group_id=5470 From noreply at sourceforge.net Thu Jun 15 14:53:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 05:53:20 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14: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=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Thu Jun 15 15:06:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 06:06:46 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Thu Jun 15 18:13:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 09:13:21 -0700 Subject: [Patches] [ python-Patches-1506760 ] Patch for 1506758 - popen2/subprocess MAXFD MemoryErrors Message-ID: Patches item #1506760, was opened at 2006-06-15 16: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=1506760&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Vetere (pav3901) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for 1506758 - popen2/subprocess MAXFD MemoryErrors Initial Comment: A simple patch to fix the problem I reported in that bug. The patch is against the release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506760&group_id=5470 From noreply at sourceforge.net Fri Jun 16 03:15:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 18:15:08 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-15 21: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=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 16 05:44:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 20:44:58 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-15 21:15 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-15 23:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 16 07:11:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 22:11:15 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Fri Jun 16 07:12:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Jun 2006 22:12:55 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-16 03:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 05:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 16 09:43:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 00:43:53 -0700 Subject: [Patches] [ python-Patches-1505257 ] winerror module Message-ID: Patches item #1505257, was opened at 2006-06-13 10:57 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Martin v. L??wis (loewis) Summary: winerror module Initial Comment: Hi Martin, unfortunately I haven't found time to work on a C based winerror module. Here's a generator and the generated Python module which defines the interface. This can then later be replaced by a more efficient C implementation. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-16 09:43 Message: Logged In: YES user_id=38388 It's a new module, so it may also come with a new interface. Note that there's not much difference between the errno module and winerror, except that you can't write winerror.ERROR, but have to do one more indirection: winerror.winerror.ERROR. The reason for having a lookup object is that the number of error symbols is huge and you'd ideally only want those symbols being loaded into the process that actually need (typically only a few). The C implementation of the lookup object will make this possible by storing the data in a static C array. I will add documentation for the module based on the errno module documentation, but not before next week - no time. I still think that the module should go in before beta1 is released. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-14 07:15 Message: Logged In: YES user_id=21627 As discussed before, I am uncomfortable with a lookup object, instead of just two dicts or dict-like objects: it's inconsistent with the errno module, and I don't see the need for it. Also, can you please provide documentation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 From noreply at sourceforge.net Fri Jun 16 09:48:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 00:48:44 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 09:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Fri Jun 16 14:11:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 05:11:20 -0700 Subject: [Patches] [ python-Patches-1507247 ] tarfile extraction does not honor umask Message-ID: Patches item #1507247, was opened at 2006-06-16 15: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=1507247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile extraction does not honor umask Initial Comment: If the upperdirs in the member file's pathname does not exist. tarfile creates those paths with 0777 permission bits and does not honor umask. This patch uses umask to set the ti.mode of the created directory for later usage in chmod. --- tarfile.py (revision 46993) +++ tarfile.py (working copy) @@ -1560,7 +1560,9 @@ ti = TarInfo() ti.name = upperdirs ti.type = DIRTYPE - ti.mode = 0777 + umask = os.umask(0) + ti.mode = 0777 - umask + os.umask(umask) ti.mtime = tarinfo.mtime ti.uid = tarinfo.uid ti.gid = tarinfo.gid ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507247&group_id=5470 From noreply at sourceforge.net Fri Jun 16 14:49:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 05:49:00 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-15 21:15 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 08:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 01:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-15 23:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 16 23:55:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 14:55:08 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-16 03:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 23:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 14:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 05:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Sat Jun 17 02:52:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 17:52:25 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-15 21:15 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 20:52 Message: Logged In: YES user_id=835142 Rationale: The container of interned strings logically a set. Current implementation that uses a dictionary with the same keys and values is clearly an artificial implementation of a set necessary in earlier versions of Python. With a proper C implementation of sets available, it is natural to use it to store interned strings. Since set and dict objects use the same lookup algorithm, this patch is not expected to affect performance and pybench does not show any difference. Since a large set is using half of the memory of the equivalent dict, this patch is expected to reduce interpretor memory usage. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 17:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 08:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 01:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-15 23:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Sat Jun 17 08:44:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Jun 2006 23:44:35 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-16 03:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 08:44 Message: Logged In: YES user_id=21627 I don't think "it's natural to do it" is a convincing object reason to change a running system. A change should address correctness, efficiency, maintainability, functionality (features), legal issues, etc. I can't see any of this in this patch, so I'm -1. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-17 02:52 Message: Logged In: YES user_id=835142 Rationale: The container of interned strings logically a set. Current implementation that uses a dictionary with the same keys and values is clearly an artificial implementation of a set necessary in earlier versions of Python. With a proper C implementation of sets available, it is natural to use it to store interned strings. Since set and dict objects use the same lookup algorithm, this patch is not expected to affect performance and pybench does not show any difference. Since a large set is using half of the memory of the equivalent dict, this patch is expected to reduce interpretor memory usage. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 23:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 14:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 05:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Sat Jun 17 09:00:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 00:00:56 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 08:53 Message generated for change (Comment added) made by geekmug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 03:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 03:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 01:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 09:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Sat Jun 17 10:38:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 01:38:23 -0700 Subject: [Patches] [ python-Patches-1507676 ] improve object.c and abstract.c exception messages Message-ID: Patches item #1507676, was opened at 2006-06-17 08:38 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=1507676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: improve object.c and abstract.c exception messages Initial Comment: This patch adds the type of the offending object to many error messages in the abstract APIs, such as "iteration over non-sequence". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 From noreply at sourceforge.net Sat Jun 17 11:15:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 02:15:50 -0700 Subject: [Patches] [ python-Patches-763580 ] Minor enhancements to Variable class Message-ID: Patches item #763580, was opened at 2003-07-01 02:18 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L??wis (loewis) Summary: Minor enhancements to Variable class Initial Comment: Here are two enhancements to the Variable class (and subclasses): 1) Variables now have a "name" argument. This works just like the name argument on almost every other Tkinter class. Its primary purpose is to allow the user to create a new Tkinter Variable given its tk name. Justification: at present there is no reasonable way to do this. One can create a new Tkinter Variable and then assign its name property, but that relies on knowing about internals and it has the ugly side effect of creating an unused tk variable I admit that setvar and getvar can be used to work around the problem, but sometimes it's nicer to use a Tkinter Variable and often it's not convenient to pass the original Variable around to where it's needed. One can get an original Tkinter widget back again given the corresponding tk widget's name. It's time to allow this for Tkinter Variables (and tkFont.Font objects, but that's a separate issue I submitted as a bug report with associated suggested simple fix). 2) Variables now have a "value" argument to specify the initial value. This shortens: avar = StringVar() avar.set("desired value") to: avar = StringVar("desired value") Justification: it's useful. It's also harmless in that it will not break any existing code. I think one can even do something like this in tcl (i.e. define a variable and set it at the same time) and it's certainly a normal thing to do in Python itself. -- Russell ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 11:15 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46998. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-20 04:53 Message: Logged In: YES user_id=80475 Martin, do you have any thoughts on this one? ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-07-01 19:30 Message: Logged In: YES user_id=431773 Replacement patch. The difference is what to do if value is supplied and the variable already exists (not something existing users would ever see unless they were doing nasty stuff directly in tcl). The old version treated value as an initial value, this new version always honors value if it is specified. I think this will be less surprising to the user (in those rare cases where it matters). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=763580&group_id=5470 From noreply at sourceforge.net Sat Jun 17 11:21:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 02:21:09 -0700 Subject: [Patches] [ python-Patches-1096231 ] Fix for wm_iconbitmap to allow .ico files under Windows. Message-ID: Patches item #1096231, was opened at 2005-01-05 05:09 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096231&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John Fouhy (johnfouhy) Assigned to: Martin v. L??wis (loewis) Summary: Fix for wm_iconbitmap to allow .ico files under Windows. Initial Comment: Tk 8.4 adds a -default option to wm iconbitmap to better support Microsoft Windows. Here is the link: http://www.tcl.tk/man/tcl8.4/TkCmd/wm.htm#M18 This is the relevant information: "On the Windows operating system, an additional flag is supported: wm iconbitmap window ?-default? ?image?. If the -default flag is given, the icon is applied to all toplevel windows (existing and future) to which no other specific icon has yet been applied. In addition to bitmap image types, a full path specification to any file which contains a valid Windows icon is also accepted (usually .ico or .icr files), or any file for which the shell has assigned an icon. Tcl will first test if the file contains an icon, then if it has an assigned icon, and finally, if that fails, test for a bitmap." This patch modifies Tkinter.py so that wm_iconbitmap supports a 'default' keyword parameter which, if used, will make the appropriate Tk call. This allows you to change your Tkinter application icons under Windows with one line of code :-) (and no need for tkIcon, hakicon, etc) For the record: I am running Windows XP Professional SP2 and Python 2.3.4. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 11:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46999. ---------------------------------------------------------------------- Comment By: Jan Claeys (janc13) Date: 2005-03-03 18:29 Message: Logged In: YES user_id=412240 I have successfully tested this with Python 2.3.5 & Python 2.4 on Windows 2000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1096231&group_id=5470 From noreply at sourceforge.net Sat Jun 17 11:25:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 02:25:36 -0700 Subject: [Patches] [ python-Patches-1494750 ] BaseWidget.destroy updates master's childern too early Message-ID: Patches item #1494750, was opened at 2006-05-25 08:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494750&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L??wis (loewis) Summary: BaseWidget.destroy updates master's childern too early Initial Comment: In BaseWidget.destroy(), it removes self from its master's dict of children before it calls the Tcl destroy on the widget. If the widget has a destroy callback (like Togl, the Tk OpenGL widget), then nametowidget throws an exception when given the widget's name even though the Python widget still exists. Just reordering the code, so that the Tcl destroy happens before the updating of the master's dict of children, fixes the problem. The bug is present in earlier versions of Tkinter too. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 11:25 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r47000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494750&group_id=5470 From noreply at sourceforge.net Sat Jun 17 11:30:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 02:30:13 -0700 Subject: [Patches] [ python-Patches-1500773 ] wm_attributes doesn't take keyword arguments Message-ID: Patches item #1500773, was opened at 2006-06-05 08:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500773&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L??wis (loewis) Summary: wm_attributes doesn't take keyword arguments Initial Comment: The Tk wm attributes command takes option arguments (from the Tk wm manual page): wm attributes window ?option value option value...? And option arguments are normally given with keyword arguments in Tkinter (most if not all widget creation functions and widget commands). The attached patch changes the wm_attributes method to take keyword arguments, so top.wm_attributes(alpha=.8) will work as expected (on Windows XP and Mac OS X). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 11:30 Message: Logged In: YES user_id=21627 This is an incompatible change. I also don't see the point; top.wm_attributes('alpha',.8) should work just fine, no? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500773&group_id=5470 From noreply at sourceforge.net Sat Jun 17 12:55:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 03:55:47 -0700 Subject: [Patches] [ python-Patches-1507676 ] improve object.c and abstract.c exception messages Message-ID: Patches item #1507676, was opened at 2006-06-17 08:38 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: improve object.c and abstract.c exception messages Initial Comment: This patch adds the type of the offending object to many error messages in the abstract APIs, such as "iteration over non-sequence". ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-17 10:55 Message: Logged In: YES user_id=4771 One message is wrong, in typeobject.c:slot_tp_hash(). The object that is unhashable is not 'func', it is 'self'. In abstract.c, maybe the two error messages from PySequence_Size() and PyMapping_Size() should be different, as they depend on the presence of a different slot. I'd suggest, respectively, "len() of non-sequence object '%.200s'" and "len() of non-mapping object '%.200s'". The rest looks good and quite useful IMHO :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 From noreply at sourceforge.net Sat Jun 17 13:20:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 04:20:27 -0700 Subject: [Patches] [ python-Patches-1507676 ] improve object.c and abstract.c exception messages Message-ID: Patches item #1507676, was opened at 2006-06-17 08:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: improve object.c and abstract.c exception messages Initial Comment: This patch adds the type of the offending object to many error messages in the abstract APIs, such as "iteration over non-sequence". ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-17 11:20 Message: Logged In: YES user_id=849994 Thanks for your review! I incorporated the changes into the 2nd version. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-17 10:55 Message: Logged In: YES user_id=4771 One message is wrong, in typeobject.c:slot_tp_hash(). The object that is unhashable is not 'func', it is 'self'. In abstract.c, maybe the two error messages from PySequence_Size() and PyMapping_Size() should be different, as they depend on the presence of a different slot. I'd suggest, respectively, "len() of non-sequence object '%.200s'" and "len() of non-mapping object '%.200s'". The rest looks good and quite useful IMHO :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 From noreply at sourceforge.net Sat Jun 17 21:18:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Jun 2006 12:18:54 -0700 Subject: [Patches] [ python-Patches-1503556 ] Allow Empty Subscript List Without Parentheses Message-ID: Patches item #1503556, was opened at 2006-06-09 17:47 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Empty Subscript List Without Parentheses Initial Comment: This is a reference implementation of PEP XXX, which makes writing "x[]" equivalent to writing "x[()]". It passes the Python test suite, but currently doesn't provide additional tests or documentation. The attached diff doesn't include changes to auto-generated files. ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2006-06-17 22:18 Message: Logged In: YES user_id=679426 Attached is an improved patch, which does exactly the same thing but with less code. It shows that, at least from the implementation's point of view, an empty tuple for an empty subscript list works like an n-tuple for an n-sized subscript list. You can also see it in http://python.pastebin.com/715221 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503556&group_id=5470 From noreply at sourceforge.net Sun Jun 18 20:00:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 11:00:44 -0700 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 06:37 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 14:00 Message: Logged In: YES user_id=1356214 Martin, I'm working on an update to this patch so that it will finally get fixed. I have a question about your answer to #4. You say that errno is read "much too late", but that's the same way that errorhandler() does it, and it seems acceptable there. I don't see any calls in between that would trash errno (at least after my patch is applied :). Is there really a problem? I do have it fixed, by returning errno from internal_select(), but if it isn't needed I'd like to simplify the patch. BTW, I'm handling #1 (internal_connect()). There is still more work to do -- I think that it would be better to handle Ctl-C as the interpreter does on its periodic checks, so that it becomes KeyboardInterrupt instead of some other error with a ' (4, ' in it. Umm, I need to do more research on that. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-02-24 15:42 Message: Logged In: YES user_id=21627 Thanks for the patch. 1) I could not see where you dealt with internal_connect in the patch. However, as a connect can also be cancelled with Ctrl-C, I think you need to deal with it, too. 2) I agree, renaming it would be good 3) you could come up with a macro to avoid code duplication (relying on consistent naming of variables, but that might confure more than help 4) This is almost right. The critical thing is that you read errno much too late. errno is meant to be read immediately after the system call. Any later system call can modify the value - including all of the pthread calls that we do in-between. So the right solution is to copy errno right after select, into a local variable of the caller, and read *that* variable. In order to avoid modifying SetFromErrno, you can assign back to errno before calling it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Sun Jun 18 20:21:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 11:21:54 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 05:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-18 11:21 Message: Logged In: YES user_id=33168 I'm ok with the idea of this patch for 2.5 if you can get in before the freeze. If you do check in, be sure to watch the buildbots. But I have some specific comments/concerns below. A couple of notes about Scott's patch. I would prefer the macro name to be HAVE_CURSES_RESIZETERM. I don't understand why there are 2 variants with and without the _. I see there are 2 different curses APIs. Does the single HAVE_ cover the cases of having is_term_resized, resize_term, and resizeterm? It seems like it might be better to have 2 or 3 configure checks. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 00:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 00:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-15 22:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 06:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Sun Jun 18 20:23:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 11:23:10 -0700 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 12:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-18 20:23 Message: Logged In: YES user_id=21627 If I understand correctly, you have Py_END_ALLOW_THREADS between the system call and the access to errno. Py_END_ALLOW_THREADS expands to PyEval_RestoreThread, which calls PyThread_acquire_lock, which (on pthreads) calls sem_wait, which may set errno to EINTR. It may well be that the same mistake is made in other places. That the code is in Python is no proof that it is "acceptable" - only that earlier reviewers did not catch the mistake. If so, this should perhaps be discussed on python-dev: if we want an explicit guarantee that errno won't change across these macros, we should change the functions to provide that guarantee. In general, you should assume that any C library call may change errno, unless it does not document the values that errno may receive due to this system call. So for any library call between the original call and the usage of errno, you have to analyse whether it may change errno (directly or indirectly). ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 20:00 Message: Logged In: YES user_id=1356214 Martin, I'm working on an update to this patch so that it will finally get fixed. I have a question about your answer to #4. You say that errno is read "much too late", but that's the same way that errorhandler() does it, and it seems acceptable there. I don't see any calls in between that would trash errno (at least after my patch is applied :). Is there really a problem? I do have it fixed, by returning errno from internal_select(), but if it isn't needed I'd like to simplify the patch. BTW, I'm handling #1 (internal_connect()). There is still more work to do -- I think that it would be better to handle Ctl-C as the interpreter does on its periodic checks, so that it becomes KeyboardInterrupt instead of some other error with a ' (4, ' in it. Umm, I need to do more research on that. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-02-24 21:42 Message: Logged In: YES user_id=21627 Thanks for the patch. 1) I could not see where you dealt with internal_connect in the patch. However, as a connect can also be cancelled with Ctrl-C, I think you need to deal with it, too. 2) I agree, renaming it would be good 3) you could come up with a macro to avoid code duplication (relying on consistent naming of variables, but that might confure more than help 4) This is almost right. The critical thing is that you read errno much too late. errno is meant to be read immediately after the system call. Any later system call can modify the value - including all of the pthread calls that we do in-between. So the right solution is to copy errno right after select, into a local variable of the caller, and read *that* variable. In order to avoid modifying SetFromErrno, you can assign back to errno before calling it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Sun Jun 18 20:50:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 11:50:25 -0700 Subject: [Patches] [ python-Patches-1505257 ] winerror module Message-ID: Patches item #1505257, was opened at 2006-06-13 10:57 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Martin v. L??wis (loewis) Summary: winerror module Initial Comment: Hi Martin, unfortunately I haven't found time to work on a C based winerror module. Here's a generator and the generated Python module which defines the interface. This can then later be replaced by a more efficient C implementation. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-18 20:50 Message: Logged In: YES user_id=38388 This will have to wait until Python 2.6... (see python-dev for discussion). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-06-16 09:43 Message: Logged In: YES user_id=38388 It's a new module, so it may also come with a new interface. Note that there's not much difference between the errno module and winerror, except that you can't write winerror.ERROR, but have to do one more indirection: winerror.winerror.ERROR. The reason for having a lookup object is that the number of error symbols is huge and you'd ideally only want those symbols being loaded into the process that actually need (typically only a few). The C implementation of the lookup object will make this possible by storing the data in a static C array. I will add documentation for the module based on the errno module documentation, but not before next week - no time. I still think that the module should go in before beta1 is released. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-14 07:15 Message: Logged In: YES user_id=21627 As discussed before, I am uncomfortable with a lookup object, instead of just two dicts or dict-like objects: it's inconsistent with the errno module, and I don't see the need for it. Also, can you please provide documentation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1505257&group_id=5470 From noreply at sourceforge.net Sun Jun 18 21:22:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 12:22:03 -0700 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 06:37 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 15:22 Message: Logged In: YES user_id=1356214 Hmm, not me, but yes, socketmodule.c wraps its system calls in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, and then does its error checking. Here's a small function (from trunk): static PyObject * sock_connect(PySocketSockObject *s, PyObject *addro) { struct sockaddr *addr; int addrlen; int res; int timeout; if (!getsockaddrarg(s, addro, &addr, &addrlen)) return NULL; Py_BEGIN_ALLOW_THREADS res = internal_connect(s, addr, addrlen, &timeout); Py_END_ALLOW_THREADS if (timeout) { PyErr_SetString(socket_timeout, "timed out"); return NULL; } if (res != 0) return s->errorhandler(); Py_INCREF(Py_None); return Py_None; } Note that both the check for timeout and also the s->errorhandler() call (which defaults to set_error() and probably pre-dates timeout) use errno, everywhere. If this is wrong, I'll bring it up on python-dev. Do you have an example of a properly-coded module? For example, the first one I checked, fctlmodule.c, does it the same way. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-18 14:23 Message: Logged In: YES user_id=21627 If I understand correctly, you have Py_END_ALLOW_THREADS between the system call and the access to errno. Py_END_ALLOW_THREADS expands to PyEval_RestoreThread, which calls PyThread_acquire_lock, which (on pthreads) calls sem_wait, which may set errno to EINTR. It may well be that the same mistake is made in other places. That the code is in Python is no proof that it is "acceptable" - only that earlier reviewers did not catch the mistake. If so, this should perhaps be discussed on python-dev: if we want an explicit guarantee that errno won't change across these macros, we should change the functions to provide that guarantee. In general, you should assume that any C library call may change errno, unless it does not document the values that errno may receive due to this system call. So for any library call between the original call and the usage of errno, you have to analyse whether it may change errno (directly or indirectly). ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 14:00 Message: Logged In: YES user_id=1356214 Martin, I'm working on an update to this patch so that it will finally get fixed. I have a question about your answer to #4. You say that errno is read "much too late", but that's the same way that errorhandler() does it, and it seems acceptable there. I don't see any calls in between that would trash errno (at least after my patch is applied :). Is there really a problem? I do have it fixed, by returning errno from internal_select(), but if it isn't needed I'd like to simplify the patch. BTW, I'm handling #1 (internal_connect()). There is still more work to do -- I think that it would be better to handle Ctl-C as the interpreter does on its periodic checks, so that it becomes KeyboardInterrupt instead of some other error with a ' (4, ' in it. Umm, I need to do more research on that. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-02-24 15:42 Message: Logged In: YES user_id=21627 Thanks for the patch. 1) I could not see where you dealt with internal_connect in the patch. However, as a connect can also be cancelled with Ctrl-C, I think you need to deal with it, too. 2) I agree, renaming it would be good 3) you could come up with a macro to avoid code duplication (relying on consistent naming of variables, but that might confure more than help 4) This is almost right. The critical thing is that you read errno much too late. errno is meant to be read immediately after the system call. Any later system call can modify the value - including all of the pthread calls that we do in-between. So the right solution is to copy errno right after select, into a local variable of the caller, and read *that* variable. In order to avoid modifying SetFromErrno, you can assign back to errno before calling it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Sun Jun 18 21:30:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 12:30:18 -0700 Subject: [Patches] [ python-Patches-1503556 ] Allow Empty Subscript List Without Parentheses Message-ID: Patches item #1503556, was opened at 2006-06-09 14:47 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Allow Empty Subscript List Without Parentheses Initial Comment: This is a reference implementation of PEP XXX, which makes writing "x[]" equivalent to writing "x[()]". It passes the Python test suite, but currently doesn't provide additional tests or documentation. The attached diff doesn't include changes to auto-generated files. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-18 19:30 Message: Logged In: YES user_id=849994 Rejected per Guido's pronouncement on python-dev. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2006-06-17 19:18 Message: Logged In: YES user_id=679426 Attached is an improved patch, which does exactly the same thing but with less code. It shows that, at least from the implementation's point of view, an empty tuple for an empty subscript list works like an n-tuple for an n-sized subscript list. You can also see it in http://python.pastebin.com/715221 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1503556&group_id=5470 From noreply at sourceforge.net Sun Jun 18 21:36:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 12:36:05 -0700 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 07:14 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 12:36 Message: Logged In: YES user_id=971153 For the record: gdb does have a "restart" command http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html (it's used to restart from a particular checkpoint) ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-06-08 01:06 Message: Logged In: YES user_id=158581 Sorry for not responding earlier. As getting this was taking a bit of time moving forward, in the interrum I had been making much faster progress by splitting this off into it's own little project under the bash debugger project I have on sourceforge (http://bashdb.sourceforge.net/pydb). Being able to make public releases earlier and oftener has offorded the oppertunity to move much further along much quicker than via the patch method (where we still haven't gotten past restarting the debugger). Now back to your comments/questions. In pydb, there are two kinds of "restart". "run" is like gdb's run. Debugger state (breakpoints, watchpoints, display expressions, debugger settings for list size, etc.) are preserved. Same as in gdb. Gdb does not to my knowledge have a command called "restart". However I've taken your suggestion of not having a "restart" be the same thing as "run". "restart" is a re-exec of the debugger. No state is save. As a debugger writer, I personally find that one useful ;-) Having the R be an alias for "run" is helpful since it's short and matches what's used Perl where people use the debugger more frequently. In fact there's a whole book written on the Perl debugger. (And I also use 'R' in the GNU Make and bash debuggers.) As for "ru", well, since I've added command completion, I feel this issue is less important. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 20:51 Message: Logged In: YES user_id=971153 one suggestion though: do we really need 'restart' alias? The main problem is that gdb uses "restart" for a very different purpose (restarting a program from a known state)..And we probably shouldn't deviate from gdb's command set unless we have to. Also I think we should not pollute the command space without a real need...(a similar argument could be made agaist "ru" abbreviation as well, but it's of lesser importance) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 20:40 Message: Logged In: YES user_id=971153 The patch works for me. I think the feature is desirable. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 13:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Sun Jun 18 22:23:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 13:23:00 -0700 Subject: [Patches] [ python-Patches-1507676 ] improve object.c and abstract.c exception messages Message-ID: Patches item #1507676, was opened at 2006-06-17 08:38 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: improve object.c and abstract.c exception messages Initial Comment: This patch adds the type of the offending object to many error messages in the abstract APIs, such as "iteration over non-sequence". ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-18 20:23 Message: Logged In: YES user_id=4771 Looks good. I think this should be checked in the trunk ASAP. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-17 11:20 Message: Logged In: YES user_id=849994 Thanks for your review! I incorporated the changes into the 2nd version. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-17 10:55 Message: Logged In: YES user_id=4771 One message is wrong, in typeobject.c:slot_tp_hash(). The object that is unhashable is not 'func', it is 'self'. In abstract.c, maybe the two error messages from PySequence_Size() and PyMapping_Size() should be different, as they depend on the presence of a different slot. I'd suggest, respectively, "len() of non-sequence object '%.200s'" and "len() of non-mapping object '%.200s'". The rest looks good and quite useful IMHO :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 From noreply at sourceforge.net Sun Jun 18 22:46:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 13:46:20 -0700 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 10:14 Message generated for change (Comment added) made by rockyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- >Comment By: Rocky Bernstein (rockyb) Date: 2006-06-18 16:46 Message: Logged In: YES user_id=158581 Tried on both GNu/Linux and NetBSD: restart Undefined command: "restart". Try "help". (gdb) show version GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". (gdb) info checkpoint Undefined info command: "checkpoint". Try "help info". ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 15:36 Message: Logged In: YES user_id=971153 For the record: gdb does have a "restart" command http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html (it's used to restart from a particular checkpoint) ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-06-08 04:06 Message: Logged In: YES user_id=158581 Sorry for not responding earlier. As getting this was taking a bit of time moving forward, in the interrum I had been making much faster progress by splitting this off into it's own little project under the bash debugger project I have on sourceforge (http://bashdb.sourceforge.net/pydb). Being able to make public releases earlier and oftener has offorded the oppertunity to move much further along much quicker than via the patch method (where we still haven't gotten past restarting the debugger). Now back to your comments/questions. In pydb, there are two kinds of "restart". "run" is like gdb's run. Debugger state (breakpoints, watchpoints, display expressions, debugger settings for list size, etc.) are preserved. Same as in gdb. Gdb does not to my knowledge have a command called "restart". However I've taken your suggestion of not having a "restart" be the same thing as "run". "restart" is a re-exec of the debugger. No state is save. As a debugger writer, I personally find that one useful ;-) Having the R be an alias for "run" is helpful since it's short and matches what's used Perl where people use the debugger more frequently. In fact there's a whole book written on the Perl debugger. (And I also use 'R' in the GNU Make and bash debuggers.) As for "ru", well, since I've added command completion, I feel this issue is less important. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 23:51 Message: Logged In: YES user_id=971153 one suggestion though: do we really need 'restart' alias? The main problem is that gdb uses "restart" for a very different purpose (restarting a program from a known state)..And we probably shouldn't deviate from gdb's command set unless we have to. Also I think we should not pollute the command space without a real need...(a similar argument could be made agaist "ru" abbreviation as well, but it's of lesser importance) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 23:40 Message: Logged In: YES user_id=971153 The patch works for me. I think the feature is desirable. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 16:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Mon Jun 19 00:07:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 15:07:25 -0700 Subject: [Patches] [ python-Patches-1472257 ] pdb: fix for #1472251('run/runeval' commands bug) Message-ID: Patches item #1472257, was opened at 2006-04-18 05:22 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb: fix for #1472251('run/runeval' commands bug) Initial Comment: This simple patch ensure that the first argument to the 'run/runeval' functions is string.See Bug #1472251 for more details. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 15:07 Message: Logged In: YES user_id=971153 I am not sure whether the original bug is indeed a bug. (see discussion of that bug)... And even if #1472251 is deemed a bug, the patch has a couple of unrelated problems: 1. bdb.py should not print anything on stdout 2. current bdb.py's run() accepts code objects, the patch breaks it. Should the patch be rejected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 From noreply at sourceforge.net Mon Jun 19 00:08:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 15:08:49 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 00:08 Message: Logged In: YES user_id=89016 The man page states: "Most of the work is done by the inner function resize_term. The outer function resizeterm adds bookkeeping for the SIGWINCH handler." All three functions are closely related and are documented on the same man page, so we should be safe with one check. I'll change the macro name and check in the patch tomorrow morning. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-18 20:21 Message: Logged In: YES user_id=33168 I'm ok with the idea of this patch for 2.5 if you can get in before the freeze. If you do check in, be sure to watch the buildbots. But I have some specific comments/concerns below. A couple of notes about Scott's patch. I would prefer the macro name to be HAVE_CURSES_RESIZETERM. I don't understand why there are 2 variants with and without the _. I see there are 2 different curses APIs. Does the single HAVE_ cover the cases of having is_term_resized, resize_term, and resizeterm? It seems like it might be better to have 2 or 3 configure checks. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 09:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 09:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Mon Jun 19 00:17:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Jun 2006 15:17:55 -0700 Subject: [Patches] [ python-Patches-1507676 ] improve object.c and abstract.c exception messages Message-ID: Patches item #1507676, was opened at 2006-06-17 08:38 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: improve object.c and abstract.c exception messages Initial Comment: This patch adds the type of the offending object to many error messages in the abstract APIs, such as "iteration over non-sequence". ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-18 22:17 Message: Logged In: YES user_id=849994 Committed in revision 47017. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-18 20:23 Message: Logged In: YES user_id=4771 Looks good. I think this should be checked in the trunk ASAP. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-17 11:20 Message: Logged In: YES user_id=849994 Thanks for your review! I incorporated the changes into the 2nd version. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-17 10:55 Message: Logged In: YES user_id=4771 One message is wrong, in typeobject.c:slot_tp_hash(). The object that is unhashable is not 'func', it is 'self'. In abstract.c, maybe the two error messages from PySequence_Size() and PyMapping_Size() should be different, as they depend on the presence of a different slot. I'd suggest, respectively, "len() of non-sequence object '%.200s'" and "len() of non-mapping object '%.200s'". The rest looks good and quite useful IMHO :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507676&group_id=5470 From noreply at sourceforge.net Mon Jun 19 10:08:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 01:08:54 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 10:08 Message: Logged In: YES user_id=89016 Checked in a version that does three separate configure checks as r47022. I'll close the patch, once all buildbot have survived the checkin. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 00:08 Message: Logged In: YES user_id=89016 The man page states: "Most of the work is done by the inner function resize_term. The outer function resizeterm adds bookkeeping for the SIGWINCH handler." All three functions are closely related and are documented on the same man page, so we should be safe with one check. I'll change the macro name and check in the patch tomorrow morning. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-18 20:21 Message: Logged In: YES user_id=33168 I'm ok with the idea of this patch for 2.5 if you can get in before the freeze. If you do check in, be sure to watch the buildbots. But I have some specific comments/concerns below. A couple of notes about Scott's patch. I would prefer the macro name to be HAVE_CURSES_RESIZETERM. I don't understand why there are 2 variants with and without the _. I see there are 2 different curses APIs. Does the single HAVE_ cover the cases of having is_term_resized, resize_term, and resizeterm? It seems like it might be better to have 2 or 3 configure checks. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 09:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 09:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Mon Jun 19 10:35:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 01:35:13 -0700 Subject: [Patches] [ python-Patches-914340 ] gzip.GzipFile to accept stream as fileobj. Message-ID: Patches item #914340, was opened at 2004-03-11 19:45 Message generated for change (Comment added) made by antialize You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile to accept stream as fileobj. Initial Comment: When gzip.GzipFile is initialized with a fileobj which does not have tell() and seek() methods (non-rewinding stream) it throws exception. The interesting thing is that it doesn't have to. The following patch updates gzip.py to allow any stream with just a read() method to be used. This is helpful if you want to be able to do something like: gzip.GzipFile(fileobj=urllib.urlopen("file:///README.gz")).readlines() or use GzipFile with sys.stdin stream. But keep in mind that seek() and rewind() methond of the GzipFile() won't for such stream even with the patch. Igor ---------------------------------------------------------------------- Comment By: Jakob Truelsen (antialize) Date: 2006-06-19 10:35 Message: Logged In: YES user_id=379876 Is there any reson this patch is not accepted? If this patch is accepted then I have a patch to urlib2 to (automaticaly) accept gzipped content as described here http://www.http-compression.com/#client_request, if there is some reson this patch is not acceptable please detail, so it can be fixed, in tired of using popen and gunzip :) ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 15:14 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 05:27 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-11 21:04 Message: Logged In: YES user_id=995711 Previous revision of the patch does not work correctly with mutliple compressed members in one stream. I've updated the patch file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 From noreply at sourceforge.net Mon Jun 19 10:59:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 01:59:18 -0700 Subject: [Patches] [ python-Patches-1508475 ] transparent gzip compression in liburl2 Message-ID: Patches item #1508475, was opened at 2006-06-19 10: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=1508475&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jakob Truelsen (antialize) Assigned to: Nobody/Anonymous (nobody) Summary: transparent gzip compression in liburl2 Initial Comment: Some webservers support gzipping things before sending them, this patch adds transparrent support for this in urllib2 (documentation http://www.http-compression.com/) This patach *requires* hash patch 914340 as a prerequirement as this enabels stream support in the gzip libary.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1508475&group_id=5470 From noreply at sourceforge.net Mon Jun 19 12:15:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 03:15:30 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 12:15 Message: Logged In: YES user_id=89016 Looks good, closing the patch. Thanks to Scoll for the patch! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 10:08 Message: Logged In: YES user_id=89016 Checked in a version that does three separate configure checks as r47022. I'll close the patch, once all buildbot have survived the checkin. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 00:08 Message: Logged In: YES user_id=89016 The man page states: "Most of the work is done by the inner function resize_term. The outer function resizeterm adds bookkeeping for the SIGWINCH handler." All three functions are closely related and are documented on the same man page, so we should be safe with one check. I'll change the macro name and check in the patch tomorrow morning. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-18 20:21 Message: Logged In: YES user_id=33168 I'm ok with the idea of this patch for 2.5 if you can get in before the freeze. If you do check in, be sure to watch the buildbots. But I have some specific comments/concerns below. A couple of notes about Scott's patch. I would prefer the macro name to be HAVE_CURSES_RESIZETERM. I don't understand why there are 2 variants with and without the _. I see there are 2 different curses APIs. Does the single HAVE_ cover the cases of having is_term_resized, resize_term, and resizeterm? It seems like it might be better to have 2 or 3 configure checks. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 09:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 09:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Mon Jun 19 12:44:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 03:44:07 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 14:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 12:44 Message: Logged In: YES user_id=89016 Oops, sorry I meant Scott! ;) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 12:15 Message: Logged In: YES user_id=89016 Looks good, closing the patch. Thanks to Scoll for the patch! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 10:08 Message: Logged In: YES user_id=89016 Checked in a version that does three separate configure checks as r47022. I'll close the patch, once all buildbot have survived the checkin. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 00:08 Message: Logged In: YES user_id=89016 The man page states: "Most of the work is done by the inner function resize_term. The outer function resizeterm adds bookkeeping for the SIGWINCH handler." All three functions are closely related and are documented on the same man page, so we should be safe with one check. I'll change the macro name and check in the patch tomorrow morning. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-18 20:21 Message: Logged In: YES user_id=33168 I'm ok with the idea of this patch for 2.5 if you can get in before the freeze. If you do check in, be sure to watch the buildbots. But I have some specific comments/concerns below. A couple of notes about Scott's patch. I would prefer the macro name to be HAVE_CURSES_RESIZETERM. I don't understand why there are 2 variants with and without the _. I see there are 2 different curses APIs. Does the single HAVE_ cover the cases of having is_term_resized, resize_term, and resizeterm? It seems like it might be better to have 2 or 3 configure checks. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 09:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 09:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 15:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Mon Jun 19 16:44:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 07:44:49 -0700 Subject: [Patches] [ python-Patches-1472257 ] pdb: fix for #1472251('run/runeval' commands bug) Message-ID: Patches item #1472257, was opened at 2006-04-18 12:22 Message generated for change (Settings changed) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 3 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb: fix for #1472251('run/runeval' commands bug) Initial Comment: This simple patch ensure that the first argument to the 'run/runeval' functions is string.See Bug #1472251 for more details. ---------------------------------------------------------------------- >Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-06-19 14:44 Message: Logged In: YES user_id=1491175 1.Why?bdb.py prints informations about breakpoints to stdout in bpprint function. 2.This is correct.Comment right before run function should be updated to point that bdb.py's run could be used also with code objects. According to the pdb's documentation, run command should be invoked only with statement given as a string.Run's argument checking and error message could be placed in pdb's run function.I included new patch.What's your opinion? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 22:07 Message: Logged In: YES user_id=971153 I am not sure whether the original bug is indeed a bug. (see discussion of that bug)... And even if #1472251 is deemed a bug, the patch has a couple of unrelated problems: 1. bdb.py should not print anything on stdout 2. current bdb.py's run() accepts code objects, the patch breaks it. Should the patch be rejected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 From noreply at sourceforge.net Mon Jun 19 16:54:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 07:54:32 -0700 Subject: [Patches] [ python-Patches-1506645 ] curses.resizeterm() Message-ID: Patches item #1506645, was opened at 2006-06-15 08:53 Message generated for change (Comment added) made by geekmug You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: curses.resizeterm() Initial Comment: This patch add curses.resizeterm() ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-19 10:54 Message: Logged In: YES user_id=383208 Haha, nice typo. No problem. Glad to help and hope to continue to do so in the future. For what it's worth, I couldn't find a platform that one of the functions but not the others (though, in fact, I could only find a Solaris box which had none). But obviously checking each of them would be wise. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 06:44 Message: Logged In: YES user_id=89016 Oops, sorry I meant Scott! ;) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 06:15 Message: Logged In: YES user_id=89016 Looks good, closing the patch. Thanks to Scoll for the patch! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-19 04:08 Message: Logged In: YES user_id=89016 Checked in a version that does three separate configure checks as r47022. I'll close the patch, once all buildbot have survived the checkin. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-18 18:08 Message: Logged In: YES user_id=89016 The man page states: "Most of the work is done by the inner function resize_term. The outer function resizeterm adds bookkeeping for the SIGWINCH handler." All three functions are closely related and are documented on the same man page, so we should be safe with one check. I'll change the macro name and check in the patch tomorrow morning. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-18 14:21 Message: Logged In: YES user_id=33168 I'm ok with the idea of this patch for 2.5 if you can get in before the freeze. If you do check in, be sure to watch the buildbots. But I have some specific comments/concerns below. A couple of notes about Scott's patch. I would prefer the macro name to be HAVE_CURSES_RESIZETERM. I don't understand why there are 2 variants with and without the _. I see there are 2 different curses APIs. Does the single HAVE_ cover the cases of having is_term_resized, resize_term, and resizeterm? It seems like it might be better to have 2 or 3 configure checks. ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-17 03:00 Message: Logged In: YES user_id=383208 I have taken the liberty (and my inability to sleep) to update this patch in accordance with the recommendation of a configure check. This version also includes is_term_resized which goes along with the resize[_]term functions. http://scottdial.com/python-dev/curses-resizeterm.diff * It is worthy of note that my version of autoconf seemed to want to quote some things that the trunk version didn't so it perhaps you'd like to run "autoconf" to be safe. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-16 03:48 Message: Logged In: YES user_id=89016 Isn't it sufficient that the code is in the #ifdef STRICT_SYSV_CURSES block? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 01:11 Message: Logged In: YES user_id=21627 AFAICT, Solaris curses does not have resize_term, so you need to add a configure test for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-06-15 09:06 Message: Logged In: YES user_id=89016 This second version adds a wrapper for resize_term() too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506645&group_id=5470 From noreply at sourceforge.net Mon Jun 19 18:53:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 09:53:25 -0700 Subject: [Patches] [ python-Patches-1508766 ] uuid documentation Message-ID: Patches item #1508766, was opened at 2006-06-20 01: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=1508766&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: George Yoshida (quiver) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: uuid documentation Initial Comment: This is a rough documentation of the uuid module. 2.5 b1 is just around the corner, but unfortunately uuid module has no documentation without its docstrings. This document is basically created by converting docstrings into TeX formats. The quality may not be high enough, yet I suspect most parts(albeit not all) of the module are covered. But I need some help. My concernes are: - Where ot put it? - How to handle constants? NAMESPACE_XXX(used for uuid3/5) RESERVED_XXX(return value of UUID.variant attribute) (I commented out RESERVED_XXX constants.) - Overall structure, wording, etc. Hopefully, one of the release team members will commit this before 2.5 b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1508766&group_id=5470 From noreply at sourceforge.net Tue Jun 20 01:25:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 16:25:54 -0700 Subject: [Patches] [ python-Patches-1462338 ] upgrade pyexpat to expat 2.0.0 Message-ID: Patches item #1462338, was opened at 2006-03-31 18:47 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462338&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) >Assigned to: Trent Mick (tmick) Summary: upgrade pyexpat to expat 2.0.0 Initial Comment: Update Modules/expat to expat 2.0.0. The only effective change in the introduction of the XML_Size typedef for the XML_GetCurrent{Column|Line}Number() functions which effectively changed the type from 'int' to 'long'. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-06-19 23:25 Message: Logged In: YES user_id=34892 Sending Include/pyexpat.h Sending Modules/_elementtree.c Deleting Modules/expat/Makefile.in Adding Modules/expat/amigaconfig.h Sending Modules/expat/expat.h Sending Modules/expat/expat_external.h Sending Modules/expat/xmlparse.c Sending Modules/expat/xmlrole.c Sending Modules/expat/xmltok.c Sending Modules/expat/xmltok.h Sending Modules/expat/xmltok_impl.c Sending Modules/expat/xmltok_ns.c Transmitting file data ........... Committed revision 47033. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 08:34 Message: Logged In: YES user_id=849994 Can this go into 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462338&group_id=5470 From noreply at sourceforge.net Tue Jun 20 02:58:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Jun 2006 17:58:14 -0700 Subject: [Patches] [ python-Patches-1509001 ] Make Lib/test/regrtest.py NetBSD 3 aware. Message-ID: Patches item #1509001, was opened at 2006-06-20 00:58 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=1509001&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Make Lib/test/regrtest.py NetBSD 3 aware. Initial Comment: Here's a patch to get test_fcntl passing on netbsd 3.0 and make regrtest.py aware of which tests are expected to skip. If someone gives this patch the 'OK' I can commit it myself. Thanks, Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509001&group_id=5470 From noreply at sourceforge.net Tue Jun 20 11:17:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 02:17:21 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 10: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=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Tue Jun 20 11:17:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 02:17:44 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 10:17 Message generated for change (Settings changed) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Tue Jun 20 17:57:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 08:57:39 -0700 Subject: [Patches] [ python-Patches-1509404 ] skip tests in test_socket__ssl when connection refused Message-ID: Patches item #1509404, was opened at 2006-06-20 08: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=1509404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: skip tests in test_socket__ssl when connection refused Initial Comment: When a socket connection is refused, it isn't a failure of the test, it could just be network issues or the site that we are trying to connect to (we really need to point all tests to python.org but I don't know if we has SSL set up). The attached patch catches socket.error and checks if it is because of a connection refusal (based on its errno). If that is the case, the test to returns, otherwise the exception is re-raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 From noreply at sourceforge.net Tue Jun 20 18:13:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 09:13:44 -0700 Subject: [Patches] [ python-Patches-1509404 ] skip tests in test_socket__ssl when connection refused Message-ID: Patches item #1509404, was opened at 2006-06-20 15:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: skip tests in test_socket__ssl when connection refused Initial Comment: When a socket connection is refused, it isn't a failure of the test, it could just be network issues or the site that we are trying to connect to (we really need to point all tests to python.org but I don't know if we has SSL set up). The attached patch catches socket.error and checks if it is because of a connection refusal (based on its errno). If that is the case, the test to returns, otherwise the exception is re-raised. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 16:13 Message: Logged In: YES user_id=849994 I'd say this is the right thing to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 From noreply at sourceforge.net Tue Jun 20 19:31:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 10:31:22 -0700 Subject: [Patches] [ python-Patches-1509404 ] skip tests in test_socket__ssl when connection refused Message-ID: Patches item #1509404, was opened at 2006-06-20 08:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: skip tests in test_socket__ssl when connection refused Initial Comment: When a socket connection is refused, it isn't a failure of the test, it could just be network issues or the site that we are trying to connect to (we really need to point all tests to python.org but I don't know if we has SSL set up). The attached patch catches socket.error and checks if it is because of a connection refusal (based on its errno). If that is the case, the test to returns, otherwise the exception is re-raised. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-20 10:31 Message: Logged In: YES user_id=357491 One vote of confidence is enough for me! Modified to raise TestSkipped instead of a bare return. Committed in rev. 47047. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 09:13 Message: Logged In: YES user_id=849994 I'd say this is the right thing to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 From noreply at sourceforge.net Tue Jun 20 23:15:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 14:15:33 -0700 Subject: [Patches] [ python-Patches-1509584 ] Small fix for sqlite3 test suite Message-ID: Patches item #1509584, was opened at 2006-06-20 23: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=1509584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard H??ring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Small fix for sqlite3 test suite Initial Comment: The attached patch is a small fix for irritating behaviour if you run the sqlite3 test suite twice in the same interpreter. The second time you will get printed tracebacks to stderr that are confusing. This can be applied before Python 2.5b1, otherwise I'll commit it myself after the freeze. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 From noreply at sourceforge.net Tue Jun 20 23:16:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 14:16:41 -0700 Subject: [Patches] [ python-Patches-1509584 ] Small fix for sqlite3 test suite Message-ID: Patches item #1509584, was opened at 2006-06-20 23:15 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Gerhard H??ring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Small fix for sqlite3 test suite Initial Comment: The attached patch is a small fix for irritating behaviour if you run the sqlite3 test suite twice in the same interpreter. The second time you will get printed tracebacks to stderr that are confusing. This can be applied before Python 2.5b1, otherwise I'll commit it myself after the freeze. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 From noreply at sourceforge.net Wed Jun 21 00:00:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 15:00:27 -0700 Subject: [Patches] [ python-Patches-1509404 ] skip tests in test_socket__ssl when connection refused Message-ID: Patches item #1509404, was opened at 2006-06-20 08:57 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: skip tests in test_socket__ssl when connection refused Initial Comment: When a socket connection is refused, it isn't a failure of the test, it could just be network issues or the site that we are trying to connect to (we really need to point all tests to python.org but I don't know if we has SSL set up). The attached patch catches socket.error and checks if it is because of a connection refusal (based on its errno). If that is the case, the test to returns, otherwise the exception is re-raised. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-20 15:00 Message: Logged In: YES user_id=357491 Well, even after a change for a typo (left off the 'or' suffix on "error"), it still didn't work; see http://www.python.org/dev/buildbot/trunk/S-390%20Debian%20trunk/builds/181/step-test/0 . I think that unfortunately, as it stands, when at the C level something is raised using PyErr_SetObject() the value argument is assigned to args, using *args, not to message. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-20 10:31 Message: Logged In: YES user_id=357491 One vote of confidence is enough for me! Modified to raise TestSkipped instead of a bare return. Committed in rev. 47047. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 09:13 Message: Logged In: YES user_id=849994 I'd say this is the right thing to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 From noreply at sourceforge.net Wed Jun 21 00:33:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Jun 2006 15:33:52 -0700 Subject: [Patches] [ python-Patches-1509584 ] Small fix for sqlite3 test suite Message-ID: Patches item #1509584, was opened at 2006-06-20 23:15 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Gerhard H??ring (ghaering) >Assigned to: Gerhard H??ring (ghaering) Summary: Small fix for sqlite3 test suite Initial Comment: The attached patch is a small fix for irritating behaviour if you run the sqlite3 test suite twice in the same interpreter. The second time you will get printed tracebacks to stderr that are confusing. This can be applied before Python 2.5b1, otherwise I'll commit it myself after the freeze. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 From noreply at sourceforge.net Wed Jun 21 13:18:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 04:18:38 -0700 Subject: [Patches] [ python-Patches-1498930 ] Generate from Unicode database instead of manualy coding. Message-ID: Patches item #1498930, was opened at 2006-06-01 17:21 Message generated for change (Comment added) made by andersch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anders Chrigstr?m (andersch) Assigned to: Martin v. L??wis (loewis) Summary: Generate from Unicode database instead of manualy coding. Initial Comment: This patch makes _PyUnicode_IsLinebreak, _PyUnicode_ToNumeric and _PyUnicode_IsWhitespace generated from the Unicode database instead of being subject to manual updates. This ought to ease the transition to Unicode version 5.0.0. Allso, the definitions of whitespaces has changed between v3.2 and v4.1 so the test had to be updated. ---------------------------------------------------------------------- >Comment By: Anders Chrigstr?m (andersch) Date: 2006-06-21 13:18 Message: Logged In: YES user_id=621306 With the beta1 out the door I thought We might rather want a minimal fix for _PyUnicode_IsWhitespace. So here one is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498930&group_id=5470 From noreply at sourceforge.net Wed Jun 21 13:44:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 04:44:38 -0700 Subject: [Patches] [ python-Patches-1509889 ] tarfile stops iteration with some longfiles Message-ID: Patches item #1509889, was opened at 2006-06-21 14: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=1509889&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile stops iteration with some longfiles Initial Comment: tarfile.py in python 2.4.3 version has a bug that makes it to stop iteration while reading members. If a file's name is longer than 100 bytes, after reading ././@LongLink header of the file in the tar archive, tarfile tries to read the actual header. But if the 100 byte of the file's name ends with "/" and it is a regular file (type is a file type). Tarfile changes it's type to a directory by thinking that it is some old tar archive format's directory member (because it seems to end with a "/"). I created a tar archive to test this case. You can find it in the attachments. My test code does this: #!/usr/bin/python import tarfile import sys tar = tarfile.open(sys.argv[1], "r") tar.list() If I run it with the prepared tar file, i get this output: faik at pardus tmp $ ./tarlist.py longfiles.tar -rwxr-xr-x faik/users 0 2006-06-21 13:03:59 this.is.a.very.long.directory.name/ -rwxr-xr-x faik/users 0 2006-06-21 13:06:17 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/ -rwxr-xr-x faik/users 0 2006-06-21 13:08:21 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/ -rw-r--r-- faik/users 19 2006-06-21 13:08:41 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS But if I run tar(1) with tvf options, i get this output: faik at pardus tmp $ tar tvf longfiles.tar drwxr-xr-x faik/users 0 2006-06-21 13:03:59 this.is.a.very.long.directory.name/ drwxr-xr-x faik/users 0 2006-06-21 13:06:17 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/ drwxr-xr-x faik/users 0 2006-06-21 13:08:21 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/ -rw-r--r-- faik/users 19 2006-06-21 13:08:41 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS -rw-r--r-- faik/users 18 2006-06-21 13:10:10 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/COPYING -rw-r--r-- faik/users 26 2006-06-21 13:09:05 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/README tarfile.py ends iteration with this member file: "this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS". Because the full directory path name length that contains the NEWS file is exactly 100 bytes long. There is also an attachment for the fix of the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509889&group_id=5470 From noreply at sourceforge.net Wed Jun 21 19:47:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 10:47:41 -0700 Subject: [Patches] [ python-Patches-1509889 ] tarfile stops iteration with some longfiles Message-ID: Patches item #1509889, was opened at 2006-06-21 11:44 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509889&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile stops iteration with some longfiles Initial Comment: tarfile.py in python 2.4.3 version has a bug that makes it to stop iteration while reading members. If a file's name is longer than 100 bytes, after reading ././@LongLink header of the file in the tar archive, tarfile tries to read the actual header. But if the 100 byte of the file's name ends with "/" and it is a regular file (type is a file type). Tarfile changes it's type to a directory by thinking that it is some old tar archive format's directory member (because it seems to end with a "/"). I created a tar archive to test this case. You can find it in the attachments. My test code does this: #!/usr/bin/python import tarfile import sys tar = tarfile.open(sys.argv[1], "r") tar.list() If I run it with the prepared tar file, i get this output: faik at pardus tmp $ ./tarlist.py longfiles.tar -rwxr-xr-x faik/users 0 2006-06-21 13:03:59 this.is.a.very.long.directory.name/ -rwxr-xr-x faik/users 0 2006-06-21 13:06:17 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/ -rwxr-xr-x faik/users 0 2006-06-21 13:08:21 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/ -rw-r--r-- faik/users 19 2006-06-21 13:08:41 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS But if I run tar(1) with tvf options, i get this output: faik at pardus tmp $ tar tvf longfiles.tar drwxr-xr-x faik/users 0 2006-06-21 13:03:59 this.is.a.very.long.directory.name/ drwxr-xr-x faik/users 0 2006-06-21 13:06:17 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/ drwxr-xr-x faik/users 0 2006-06-21 13:08:21 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/ -rw-r--r-- faik/users 19 2006-06-21 13:08:41 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS -rw-r--r-- faik/users 18 2006-06-21 13:10:10 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/COPYING -rw-r--r-- faik/users 26 2006-06-21 13:09:05 this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/README tarfile.py ends iteration with this member file: "this.is.a.very.long.directory.name/this.is.another.very.long.directory.name/and.this.is.another.one/NEWS". Because the full directory path name length that contains the NEWS file is exactly 100 bytes long. There is also an attachment for the fix of the bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-21 17:47 Message: Logged In: YES user_id=849994 This is fixed in SVN, you can try the 2.5 beta to verify it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509889&group_id=5470 From noreply at sourceforge.net Wed Jun 21 19:53:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 10:53:45 -0700 Subject: [Patches] [ python-Patches-1509001 ] Make Lib/test/regrtest.py NetBSD 3 aware. Message-ID: Patches item #1509001, was opened at 2006-06-20 00:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509001&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Make Lib/test/regrtest.py NetBSD 3 aware. Initial Comment: Here's a patch to get test_fcntl passing on netbsd 3.0 and make regrtest.py aware of which tests are expected to skip. If someone gives this patch the 'OK' I can commit it myself. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-21 17:53 Message: Logged In: YES user_id=849994 Thanks, committed as rev. 47058, 47059. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509001&group_id=5470 From noreply at sourceforge.net Wed Jun 21 21:32:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 12:32:26 -0700 Subject: [Patches] [ python-Patches-1509404 ] skip tests in test_socket__ssl when connection refused Message-ID: Patches item #1509404, was opened at 2006-06-20 08:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: skip tests in test_socket__ssl when connection refused Initial Comment: When a socket connection is refused, it isn't a failure of the test, it could just be network issues or the site that we are trying to connect to (we really need to point all tests to python.org but I don't know if we has SSL set up). The attached patch catches socket.error and checks if it is because of a connection refusal (based on its errno). If that is the case, the test to returns, otherwise the exception is re-raised. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-21 12:32 Message: Logged In: YES user_id=357491 rev. 47053 has the change to get the errno out of exc.argx[0]. Also changed back to a bare return but also prints out why the test was skipped. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-20 15:00 Message: Logged In: YES user_id=357491 Well, even after a change for a typo (left off the 'or' suffix on "error"), it still didn't work; see http://www.python.org/dev/buildbot/trunk/S-390%20Debian%20trunk/builds/181/step-test/0 . I think that unfortunately, as it stands, when at the C level something is raised using PyErr_SetObject() the value argument is assigned to args, using *args, not to message. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-20 10:31 Message: Logged In: YES user_id=357491 One vote of confidence is enough for me! Modified to raise TestSkipped instead of a bare return. Committed in rev. 47047. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-20 09:13 Message: Logged In: YES user_id=849994 I'd say this is the right thing to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509404&group_id=5470 From noreply at sourceforge.net Wed Jun 21 21:43:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 12:43:53 -0700 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 18:04 Message generated for change (Comment added) made by jbowes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 14:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Wed Jun 21 22:55:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Jun 2006 13:55:51 -0700 Subject: [Patches] [ python-Patches-1509584 ] Small fix for sqlite3 test suite Message-ID: Patches item #1509584, was opened at 2006-06-20 23:15 Message generated for change (Settings changed) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Gerhard H??ring (ghaering) Assigned to: Gerhard H??ring (ghaering) Summary: Small fix for sqlite3 test suite Initial Comment: The attached patch is a small fix for irritating behaviour if you run the sqlite3 test suite twice in the same interpreter. The second time you will get printed tracebacks to stderr that are confusing. This can be applied before Python 2.5b1, otherwise I'll commit it myself after the freeze. ---------------------------------------------------------------------- >Comment By: Gerhard H??ring (ghaering) Date: 2006-06-21 22:55 Message: Logged In: YES user_id=163326 Comitted after beta1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509584&group_id=5470 From noreply at sourceforge.net Thu Jun 22 13:39:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 04:39:01 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 09:17 Message generated for change (Comment added) made by peterschwalm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-22 11:39 Message: Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Thu Jun 22 14:01:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 05:01:38 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 10:17 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-06-22 13:01 Message: Logged In: YES user_id=113328 Please note: 1. Prior to the existence of the free Toolkit compiler, there was no supported method for building Python with a free compiler. It's sad (and annoying) that MS withdrew the compiler version just as support was added to Python, but it's just a reversion to the prior situation. 2. Building extensions is a separate issue, which is more related to the compiler used to build the official binaries than to what options exist for building Python for yourself. 3. If you want to build extensions for Python, you can use mingw (gcc) as well as MSVC. This has been supported for a long time now. 4. Mingw does not currently support linking with msvcr80.dll, so if the official Python build moves to VC8, we will lose the option of building extensions with mingw. Therefore, I see no advantage to switching the official builds to VC8, in terms of extension building. You gain VC 2005 Express as an option, but lose mingw. As mingw is a long-established option, you in effect lose because you've gone from a well-tested option to a new, relatively untried one. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-22 12:39 Message: Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Thu Jun 22 18:34:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 09:34:13 -0700 Subject: [Patches] [ python-Patches-1060577 ] bdist_rpm not able to compile multiple rpm packages Message-ID: Patches item #1060577, was opened at 2004-11-04 17:28 Message generated for change (Comment added) made by misa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1060577&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm not able to compile multiple rpm packages Initial Comment: bdist_rpm tries to deal with debuginfo packages by naming them in the source. Just as debuginfo packages are artifacts of a buildystem, one can modify the buildsystem to create various other rpms even though the spec file only creates one. The attached patch tries to approach the solution in a more general way, by looking at the spec file and extracting the names of rpms that are going to be generated. This patch has been posted at some point on the distutils-sig mailing list: http://mail.python.org/pipermail/distutils-sig/2004-June/003953.html I assumed it already made it in, apparently not. ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2006-06-22 12:34 Message: Logged In: YES user_id=205865 Updated patch for python 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1060577&group_id=5470 From noreply at sourceforge.net Thu Jun 22 22:31:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 13:31:32 -0700 Subject: [Patches] [ python-Patches-1506760 ] Patch for 1506758 - popen2/subprocess MAXFD MemoryErrors Message-ID: Patches item #1506760, was opened at 2006-06-15 18:13 Message generated for change (Settings changed) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506760&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter Vetere (pav3901) >Assigned to: Peter ? strand (astrand) Summary: Patch for 1506758 - popen2/subprocess MAXFD MemoryErrors Initial Comment: A simple patch to fix the problem I reported in that bug. The patch is against the release24-maint branch. ---------------------------------------------------------------------- >Comment By: Peter ? strand (astrand) Date: 2006-06-22 22:31 Message: Logged In: YES user_id=344921 Patch applied, both on trunk (r47077) and on release24-maint(r47078). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1506760&group_id=5470 From noreply at sourceforge.net Fri Jun 23 01:08:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Jun 2006 16:08:36 -0700 Subject: [Patches] [ python-Patches-1510987 ] test_grp.py doesn't skip special NIS entry, fails Message-ID: Patches item #1510987, was opened at 2006-06-22 16:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1510987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mat Martineau (martineau) Assigned to: Nobody/Anonymous (nobody) Summary: test_grp.py doesn't skip special NIS entry, fails Initial Comment: Lib/test/test_grp.py is failing due to a "+:::" line in /etc/group. The test_errors() method checks for (and ignores) this type of entry, but test_values() does not. This patch makes test_values() ignore '+' or blank entries, using the same logic as test_errors(). Python: 2.5b1 (svn revision 47078) Platform: Linux 2.6.16 (Suse 10.1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1510987&group_id=5470 From noreply at sourceforge.net Fri Jun 23 15:31:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Jun 2006 06:31:32 -0700 Subject: [Patches] [ python-Patches-1511317 ] socket.gethostbyaddr fix for machines with incomplete DNS Message-ID: Patches item #1511317, was opened at 2006-06-23 13: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=1511317&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles Schwieters (chuckorama) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyaddr fix for machines with incomplete DNS Initial Comment: I found that socket.gethostbyaddr would crash 2.4.3 on machines with incomplete DNS, such as scyld cluster nodes. The following one line obvious patch fixes the problem. Charles ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1511317&group_id=5470 From noreply at sourceforge.net Sat Jun 24 19:19:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 10:19:58 -0700 Subject: [Patches] [ python-Patches-1511853 ] Speed up decimal object construction Message-ID: Patches item #1511853, was opened at 2006-06-25 03: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=1511853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Speed up decimal object construction Initial Comment: The numerical programming discussion on python-dev reminded me to try out the new profiler on the decimal module. It showed more than a quarter of the execution time for the unit tests was being spent in decimal.__new__ and in doing isinstance checks. This patch adds fast paths that avoids the isinstance checks when dealing solely with builtin types. It also caches a couple of incidental values when checking for special Decimal values during construction from a string instead of making the same function calls twice. However, while the speed benefit was significant under profiling (saving around 15 seconds on the 60 second runtime of the decimal unit tests), it was far less impressive under normal operation (saving around 0.5 seconds on the 12.5 second run time of the unit tests, and around 5 seconds on the 530+ seconds needed to run the full telco.py benchmark). So it's definitely faster, but the real magnitude of the benefit is still an open question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1511853&group_id=5470 From noreply at sourceforge.net Sun Jun 25 04:30:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 19:30:06 -0700 Subject: [Patches] [ python-Patches-1511853 ] Speed up decimal object construction Message-ID: Patches item #1511853, was opened at 2006-06-25 03:19 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1511853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Speed up decimal object construction Initial Comment: The numerical programming discussion on python-dev reminded me to try out the new profiler on the decimal module. It showed more than a quarter of the execution time for the unit tests was being spent in decimal.__new__ and in doing isinstance checks. This patch adds fast paths that avoids the isinstance checks when dealing solely with builtin types. It also caches a couple of incidental values when checking for special Decimal values during construction from a string instead of making the same function calls twice. However, while the speed benefit was significant under profiling (saving around 15 seconds on the 60 second runtime of the decimal unit tests), it was far less impressive under normal operation (saving around 0.5 seconds on the 12.5 second run time of the unit tests, and around 5 seconds on the 530+ seconds needed to run the full telco.py benchmark). So it's definitely faster, but the real magnitude of the benefit is still an open question. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-06-25 12:30 Message: Logged In: YES user_id=1038590 Raymond suggested the minor speed improvement wasn't worth the additional code complexity. I agree with that sentiment, so this one goes into the bit bucket. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1511853&group_id=5470 From noreply at sourceforge.net Sun Jun 25 06:51:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Jun 2006 21:51:52 -0700 Subject: [Patches] [ python-Patches-1512007 ] ast branch changed interactive module name Message-ID: Patches item #1512007, was opened at 2006-06-25 00: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=1512007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: ast branch changed interactive module name Initial Comment: Python 2.4 displays tracebacks interactively like this: Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: integer division or modulo by zero Python 2.5b1 displays them like this: Traceback (most recent call last): File "", line 1, in ZeroDivisionError: integer division or modulo by zero This doesn't seem likely a particularly good change and it breaks tests which rely on the particular spelling of this message. I probably wouldn't mind the change if it were to a more useful string than "", but "?" seemed better than the current state. If anything is /not/ a module, it's an interactive session with the interpreter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512007&group_id=5470 From noreply at sourceforge.net Sun Jun 25 18:25:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Jun 2006 09:25:58 -0700 Subject: [Patches] [ python-Patches-1472257 ] pdb: fix for #1472251('run/runeval' commands bug) Message-ID: Patches item #1472257, was opened at 2006-04-18 05:22 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 3 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb: fix for #1472251('run/runeval' commands bug) Initial Comment: This simple patch ensure that the first argument to the 'run/runeval' functions is string.See Bug #1472251 for more details. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-25 09:25 Message: Logged In: YES user_id=971153 ...1.Why?bdb.py prints informations about breakpoints to stdout in bpprint function.... I am not sure printing to stdout in bpprint was a good decision! Really, if bdb is intended to be a low-level debugging module, it should not print anything to stdout... ..I included new patch.What's your opinion?... A couple of comments: 1) the latest pdb's output goes through redirection. The patch does not.. 2) Is it really necessary to restrict pdb's run() to strings? Being able to pass a code object seems like a useful thing (I know that pdb docs explicitly say that the 1st arg must be a string) 3) finally, I guess I am not sure about the general approach to argument type checking in stdlib. (is it really pdb's business to check run() arguments? E.g if bdb's run() supports other types (say, UserString or file), pdb's type checking would have to change)... I guess, I am -0 on this patch.. ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-06-19 07:44 Message: Logged In: YES user_id=1491175 1.Why?bdb.py prints informations about breakpoints to stdout in bpprint function. 2.This is correct.Comment right before run function should be updated to point that bdb.py's run could be used also with code objects. According to the pdb's documentation, run command should be invoked only with statement given as a string.Run's argument checking and error message could be placed in pdb's run function.I included new patch.What's your opinion? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 15:07 Message: Logged In: YES user_id=971153 I am not sure whether the original bug is indeed a bug. (see discussion of that bug)... And even if #1472251 is deemed a bug, the patch has a couple of unrelated problems: 1. bdb.py should not print anything on stdout 2. current bdb.py's run() accepts code objects, the patch breaks it. Should the patch be rejected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 From suporte at tim.com.br Mon Jun 26 05:52:47 2006 From: suporte at tim.com.br (TIM) Date: Sun, 25 Jun 2006 23:52:47 -0400 Subject: [Patches] TIM, VIVENDO SEM FRONTEIRAS! Message-ID: <023dbc0edc16aaeaa13d40affec70fd5@> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20060625/2e1e6270/attachment.htm From noreply at sourceforge.net Mon Jun 26 21:47:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Jun 2006 12:47:08 -0700 Subject: [Patches] [ python-Patches-1512942 ] Improves an error message from setattr Message-ID: Patches item #1512942, was opened at 2006-06-26 15: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=1512942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Improves an error message from setattr Initial Comment: Fixes Bugs item #1506776 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 From noreply at sourceforge.net Tue Jun 27 11:18:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 02:18:52 -0700 Subject: [Patches] [ python-Patches-1513206 ] [FIX][Bug 1512695] cPickle.loads seg. faults Message-ID: Patches item #1513206, was opened at 2006-06-27 12:18 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=1513206&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: [FIX][Bug 1512695] cPickle.loads seg. faults Initial Comment: Attached patch fixes bug 1512695. Patch is against the svn trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513206&group_id=5470 From noreply at sourceforge.net Tue Jun 27 11:22:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 02:22:02 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-05-31 13:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 05:22 Message: Logged In: YES user_id=1344176 I've updated the patch per jackdied's suggestion, plus improved the test suite a bit. The patch is now against r47103. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 16:13 Message: Logged In: YES user_id=591932 The patch can be simplified by always calling PySequence_Tuple() and doing the decref instead of special casing tuples. If you pass PySequence_Tuple() a tuple it will incref it and hand it back to you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-05-31 21:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Tue Jun 27 12:20:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 03:20:25 -0700 Subject: [Patches] [ python-Patches-1513249 ] Remove reduce() Message-ID: Patches item #1513249, was opened at 2006-06-27 06: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=1513249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove reduce() Initial Comment: This patch removes the built-in reduce() function, including its documentation and tests. This patch is against r47103. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 From noreply at sourceforge.net Tue Jun 27 14:15:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 05:15:33 -0700 Subject: [Patches] [ python-Patches-1513299 ] Clean up usage of map() in the stdlib Message-ID: Patches item #1513299, was opened at 2006-06-27 08: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=1513299&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Clean up usage of map() in the stdlib Initial Comment: This patch cleans up the usage of map() in the standard library. Among other things, it removes several usages of things like map(None, x), as well as simplifying a number of map(lambda: ..., x) expressions. This patch is against r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 From noreply at sourceforge.net Tue Jun 27 14:22:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 05:22:47 -0700 Subject: [Patches] [ python-Patches-1498363 ] Improve super() objects support for implicit method calls Message-ID: Patches item #1498363, was opened at 2006-05-31 13:31 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Improve super() objects support for implicit method calls Initial Comment: The attached patch lets super() objects pass on implicit __getitem__, __setitem__, __delitem__, __len__ and __hash__ calls. For example, to use len() with super() objects, one must currently do something like super(X, X()).__len__() Likewise for __getitem__, super(X, X()).__getitem__(item) That's ugly. This patch lets these be spelled as len(super(X, X())) and super(X, X())[item], respectively. The patch also includes documentation updates and tests for the new functionality. The patch was taken against r46582. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 08:22 Message: Logged In: YES user_id=1344176 The patch has been updated to reflect the current SVN state, r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 From noreply at sourceforge.net Tue Jun 27 14:31:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 05:31:30 -0700 Subject: [Patches] [ python-Patches-1500609 ] Remove dependencies on the sets module Message-ID: Patches item #1500609, was opened at 2006-06-04 16:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove dependencies on the sets module Initial Comment: The attached patch removes several lingering dependencies on the deprecated sets module, replacing them with usages of the now-builtin set type. The patch is against r46648. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 08:31 Message: Logged In: YES user_id=1344176 The patch has been updated to reflect SVN as of r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500609&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:20:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:20:44 -0700 Subject: [Patches] [ python-Patches-1513249 ] Remove reduce() Message-ID: Patches item #1513249, was opened at 2006-06-27 06:20 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove reduce() Initial Comment: This patch removes the built-in reduce() function, including its documentation and tests. This patch is against r47103. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:20 Message: Logged In: YES user_id=1344176 Would you like to see map, filter, reduce all moved to functools? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:19 Message: Logged In: YES user_id=764593 This recreates a reduce in csv. Wouldn't it make more sense to move reduce to functools, and import it from there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:24:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:24:45 -0700 Subject: [Patches] [ python-Patches-1513299 ] Clean up usage of map() in the stdlib Message-ID: Patches item #1513299, was opened at 2006-06-27 08:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Clean up usage of map() in the stdlib Initial Comment: This patch cleans up the usage of map() in the standard library. Among other things, it removes several usages of things like map(None, x), as well as simplifying a number of map(lambda: ..., x) expressions. This patch is against r47124. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:24 Message: Logged In: YES user_id=1344176 Which ones would you like to see reverted (ie, which ones are not an improvement)? I've found some more cases that can be improved, so a new version of the patch will be on the way shortly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:15 Message: Logged In: YES user_id=764593 Some cases are definately an improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:42:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:42:56 -0700 Subject: [Patches] [ python-Patches-1513249 ] Remove reduce() Message-ID: Patches item #1513249, was opened at 2006-06-27 06:20 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove reduce() Initial Comment: This patch removes the built-in reduce() function, including its documentation and tests. This patch is against r47103. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:42 Message: Logged In: YES user_id=1344176 I've changed my local version to improve the difflib change, per Jim's suggestion. I'm working on a combined patch that will remove reduce, filter and map all in one go, so I'm going to close this one. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:24 Message: Logged In: YES user_id=764593 If the difflib change, couldn't + matches = 0 + for triple in self.get_matching_blocks(): + matches += triple[-1] be further simplified to matches=sum(triple[-1] for triple in self.get_matching_blocks()) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:20 Message: Logged In: YES user_id=1344176 Would you like to see map, filter, reduce all moved to functools? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:19 Message: Logged In: YES user_id=764593 This recreates a reduce in csv. Wouldn't it make more sense to move reduce to functools, and import it from there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:43:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:43:56 -0700 Subject: [Patches] [ python-Patches-1513249 ] Remove reduce() Message-ID: Patches item #1513249, was opened at 2006-06-27 06:20 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Later Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove reduce() Initial Comment: This patch removes the built-in reduce() function, including its documentation and tests. This patch is against r47103. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:42 Message: Logged In: YES user_id=1344176 I've changed my local version to improve the difflib change, per Jim's suggestion. I'm working on a combined patch that will remove reduce, filter and map all in one go, so I'm going to close this one. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:24 Message: Logged In: YES user_id=764593 If the difflib change, couldn't + matches = 0 + for triple in self.get_matching_blocks(): + matches += triple[-1] be further simplified to matches=sum(triple[-1] for triple in self.get_matching_blocks()) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:20 Message: Logged In: YES user_id=1344176 Would you like to see map, filter, reduce all moved to functools? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:19 Message: Logged In: YES user_id=764593 This recreates a reduce in csv. Wouldn't it make more sense to move reduce to functools, and import it from there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:46:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:46:14 -0700 Subject: [Patches] [ python-Patches-1513299 ] Clean up usage of map() in the stdlib Message-ID: Patches item #1513299, was opened at 2006-06-27 08:15 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Clean up usage of map() in the stdlib Initial Comment: This patch cleans up the usage of map() in the standard library. Among other things, it removes several usages of things like map(None, x), as well as simplifying a number of map(lambda: ..., x) expressions. This patch is against r47124. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:46 Message: Logged In: YES user_id=764593 There are none I would suggest reverting; it is just that some are clear wins and others are not so important. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:24 Message: Logged In: YES user_id=1344176 Which ones would you like to see reverted (ie, which ones are not an improvement)? I've found some more cases that can be improved, so a new version of the patch will be on the way shortly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:15 Message: Logged In: YES user_id=764593 Some cases are definately an improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 From noreply at sourceforge.net Tue Jun 27 17:51:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 08:51:18 -0700 Subject: [Patches] [ python-Patches-1513249 ] Remove reduce() Message-ID: Patches item #1513249, was opened at 2006-06-27 03:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Closed Resolution: Later Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove reduce() Initial Comment: This patch removes the built-in reduce() function, including its documentation and tests. This patch is against r47103. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-06-27 08:51 Message: Logged In: YES user_id=357491 Just to answer your question about map and filter, Collin: just rip them out. Generator comprehensions take care of both cases. reduce() is the only thing worth moving to functools. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 08:42 Message: Logged In: YES user_id=1344176 I've changed my local version to improve the difflib change, per Jim's suggestion. I'm working on a combined patch that will remove reduce, filter and map all in one go, so I'm going to close this one. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 08:24 Message: Logged In: YES user_id=764593 If the difflib change, couldn't + matches = 0 + for triple in self.get_matching_blocks(): + matches += triple[-1] be further simplified to matches=sum(triple[-1] for triple in self.get_matching_blocks()) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 08:20 Message: Logged In: YES user_id=1344176 Would you like to see map, filter, reduce all moved to functools? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 08:19 Message: Logged In: YES user_id=764593 This recreates a reduce in csv. Wouldn't it make more sense to move reduce to functools, and import it from there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 From noreply at sourceforge.net Tue Jun 27 18:53:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 09:53:41 -0700 Subject: [Patches] [ python-Patches-1513299 ] Clean up usage of map() in the stdlib Message-ID: Patches item #1513299, was opened at 2006-06-27 08:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Clean up usage of map() in the stdlib Initial Comment: This patch cleans up the usage of map() in the standard library. Among other things, it removes several usages of things like map(None, x), as well as simplifying a number of map(lambda: ..., x) expressions. This patch is against r47124. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-27 12:53 Message: Logged In: YES user_id=1344176 Updated the patch to r47131 and added a bunch of new cleanups. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:46 Message: Logged In: YES user_id=764593 There are none I would suggest reverting; it is just that some are clear wins and others are not so important. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:24 Message: Logged In: YES user_id=1344176 Which ones would you like to see reverted (ie, which ones are not an improvement)? I've found some more cases that can be improved, so a new version of the patch will be on the way shortly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:15 Message: Logged In: YES user_id=764593 Some cases are definately an improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 From noreply at sourceforge.net Wed Jun 28 02:50:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 17:50:47 -0700 Subject: [Patches] [ python-Patches-1513695 ] new turtle module Message-ID: Patches item #1513695, was opened at 2006-06-28 00: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=1513695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: new turtle module Initial Comment: The file, at present named xturtle.py is a reimplementation of turtle.py with additional features, among them: -Better animation of the turtle movements, especially of turning the turtle. So the turtles can more easily be used as a visual feedback instrument by the (beginning) programmer. -Different turtle shapes, gif-images as turtle shapes, user defined and user controllable turtle shapes, among them compound (multicolored) shapes. -Fine control over turtle movement and screen updates via delay(), and enhanced tracer() and speed(), update() methods. -Aliases for the most commonly used commands, like fd for forward etc. ... -Some simple commands/methods for creating event driven programs (mouse-, key-, timer-events). Especially useful for programming simple games. -A scrollable Canvas class. The scrollable Canvas can be extended interactively as needed while playing around with the turtle(s) (e. g. to follow some escaped turtle). -Commands for controlling background color or background image. detailed documentation is in the docstrings (similar to the last version of turtle.py) which copmrise approx. 50% of the filesize. xturtle.py is widely backward compatible to turtle.py (i. e. except the appearance of the turtle(s) and their animation) I propose to replace turtle.py by xturtle.py Separate Documentation is available as a text file reassembled and enhanced from the docstring. I'll supply this in a separate patch (as it seems impossible here to attach 2 files) Regards, Gregor Lingl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513695&group_id=5470 From noreply at sourceforge.net Wed Jun 28 02:59:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 17:59:00 -0700 Subject: [Patches] [ python-Patches-1513699 ] docs for xturtle.py Message-ID: Patches item #1513699, was opened at 2006-06-28 00: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=1513699&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: docs for xturtle.py Initial Comment: This is a compiled docfile for xturtle.py. Methods, (and functions) are grouped in functional groups (sections). Some information on the structure of the module is added. (At present more information as well as example scripts can be found at http://ada.rg16.asn-wien.ac.at/~python/xturtle) Regards, Gregor Lingl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513699&group_id=5470 From noreply at sourceforge.net Wed Jun 28 08:43:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Jun 2006 23:43:16 -0700 Subject: [Patches] [ python-Patches-1513206 ] [FIX][Bug 1512695] cPickle.loads seg. faults Message-ID: Patches item #1513206, was opened at 2006-06-27 09:18 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513206&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: [FIX][Bug 1512695] cPickle.loads seg. faults Initial Comment: Attached patch fixes bug 1512695. Patch is against the svn trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513206&group_id=5470 From noreply at sourceforge.net Wed Jun 28 11:42:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 02:42:33 -0700 Subject: [Patches] [ python-Patches-1513870 ] Move reduce() to functools Message-ID: Patches item #1513870, was opened at 2006-06-28 05: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=1513870&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Move reduce() to functools Initial Comment: As a follow-up to patch #1513249, this patch moves reduce() from builtins and into functools. All related documentation and tests have been changed over as well. The patch is against r47141. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513870&group_id=5470 From noreply at sourceforge.net Wed Jun 28 11:43:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 02:43:15 -0700 Subject: [Patches] [ python-Patches-1513249 ] Remove reduce() Message-ID: Patches item #1513249, was opened at 2006-06-27 06:20 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Closed Resolution: Later Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove reduce() Initial Comment: This patch removes the built-in reduce() function, including its documentation and tests. This patch is against r47103. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-06-28 05:43 Message: Logged In: YES user_id=1344176 This patch has been superseded by path #1513870. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-27 11:51 Message: Logged In: YES user_id=357491 Just to answer your question about map and filter, Collin: just rip them out. Generator comprehensions take care of both cases. reduce() is the only thing worth moving to functools. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:42 Message: Logged In: YES user_id=1344176 I've changed my local version to improve the difflib change, per Jim's suggestion. I'm working on a combined patch that will remove reduce, filter and map all in one go, so I'm going to close this one. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:24 Message: Logged In: YES user_id=764593 If the difflib change, couldn't + matches = 0 + for triple in self.get_matching_blocks(): + matches += triple[-1] be further simplified to matches=sum(triple[-1] for triple in self.get_matching_blocks()) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 11:20 Message: Logged In: YES user_id=1344176 Would you like to see map, filter, reduce all moved to functools? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:19 Message: Logged In: YES user_id=764593 This recreates a reduce in csv. Wouldn't it make more sense to move reduce to functools, and import it from there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513249&group_id=5470 From noreply at sourceforge.net Wed Jun 28 12:36:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 03:36:22 -0700 Subject: [Patches] [ python-Patches-1512942 ] Improves an error message from setattr Message-ID: Patches item #1512942, was opened at 2006-06-26 19:47 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Improves an error message from setattr Initial Comment: Fixes Bugs item #1506776 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-06-28 10:36 Message: Logged In: YES user_id=4771 The error message can still be wrong. For example, in the following situation: class X(object): __slots__ = ['a'] X().b = 5 Then the original message -- no attribute 'b' -- was correct. With this patch Python now wrongly tells you that 'X' object has only read-only attributes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 From noreply at sourceforge.net Thu Jun 29 04:29:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Jun 2006 19:29:18 -0700 Subject: [Patches] [ python-Patches-1454481 ] Make thread stack size runtime tunable Message-ID: <200606290229.k5T2TISN009824@sc8-sf-db2-new-b.sourceforge.net> Patches item #1454481, was opened at 03/20/06 04:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Make thread stack size runtime tunable Initial Comment: Platform default thread stack sizes vary considerably. Some are very generous (Win32: usually 1MB; Linux: 1MB, sometimes 8MB). Others are not (FreeBSD: 64k). Some platforms have restricted virtual address space OS/2: 512M less overhead) which makes hard coding a generous default thread stack size problematic. Some platforms thread commit stack address space, even though the memory backing it may not be committed (Windows, OS/2 at least). Some applications have a thirst for stack space in threads (Zope). Some programmers want to be able to use lots of threads, even in the face of sound advice about the lack of wisdom in this approach. The current approach to stack space management in threads in Python uses a hard coded strategy, relying on the platform having a useful default or relying on the system administrator or distribution builder over-riding the default at compile time. This patch is intended to allow developers some control over managing this resource from within Python code by way of a function in the thread module. As written, it is not intended to provide unlimited flexibility; that would probably require exposing the underlying mechanism as an option on the creation of each thread. An alternative approach to providing the functionality would be to use an environment variable to provide the information to the thread module. This has its pros and cons, in terms of flexibility and ease of use, and could be complementary to the approach implemented. The patch has been tested on OS/2 and FreeBSD 4.8. I have no means of testing the code on Win32 or Linux, though Linux is a pthread environment as is FreeBSD. Code base is SVN head from a few hours ago. A doc update is included. While I would like to see this functionality in Python 2.5, it is not a critical issue. Critique of the approach and implementation welcome. Something not addressed is the issue of tests, primarily because I haven't been able to think of a viable testing strategy - I'm all ears to suggestions for this. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 06/28/06 19:29 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 06/13/06 19:05 Message: Logged In: YES user_id=250749 Checked in to trunk after further revision in r46919, with minor test tweaks in r46925 & r46929. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 05/25/06 07:47 Message: Logged In: YES user_id=250749 Ok, v3 includes the additions to the threading module, tests in both test_thread and test_threading and docs in both thread and threading modules (duplicated as I don't know how to do the LaTex linking). If there are no other issues needing to be addressed, I propose to check these changes in sometime on the weekend of June 3-4 or thereabouts to get in a bit before the beta release. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 04/23/06 13:25 Message: Logged In: YES user_id=31435 Right, this one: "a simple shadow of the function as a module level function". If it affects all threads (which it does), then a module function is a natural place for it. If I a saw a method on the Thread class, the most natural (to me ;-)) assumption is that a_thread.stack_size(N) would set the stack size for the specific thread `a_thread`, but not affect other threads. Part of what makes that "the most natural" assumption is that Thread has no class or static methods today. As a module-level function, no such confusion is sanely possible. Sticking "stack_size" in threading.__all__, and adding from thread import stack_size to threading.py is all I'm looking for here. Well, plus docs and a test case ;-) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 04/22/06 22:35 Message: Logged In: YES user_id=250749 Thanks Tim. My default action is to try and match the prevailing style, but cut'n'paste propagated the flaw. thread_pthread.h was clean AFAICS, so I'll do a style normalisation (as a separate checkin) on thread_nt.py and thread_os2.h when commit time comes. As an "implementation detail", I hadn't considered that exposing it via threading was appropriate. I can see 2 approaches: - a simple shadow of the function as a module level function; or - a classmethod of the Thread class. Any hints on which would be the more preferable or natural approach? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 04/21/06 22:46 Message: Logged In: YES user_id=31435 The patch applies cleanly on WinXP, "and works" (I checked this by setting various stack sizes, spawning a thread doing nothing but a raw_input(), and looking at the VM size under Task Manager while the thread was paused waiting for input -- the VM size went up each time roughly by the stack-size increase; finally set stack_size to 0 again, and all the "extra" VM went away). Note that Python C style for defining functions puts the function name in the first column. For example, """ static int _pythread_nt_set_stacksize(size_t size) """ instead of """ static int _pythread_nt_set_stacksize(size_t size) """ The patch isn't consistent about this, and perhaps it's errenously ;-) aping bad style in surrounding function definitions. This should really be exposed via threading.py. `thread` is increasingly "just an implementation detail" of `threading`, and it actually felt weird to me to write a test program that had to import `thread`. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 04/14/06 05:51 Message: Logged In: YES user_id=250749 I have updated the patch along the lines Martin suggested. I have omitted OS/2 from the list of supported platforms in the doc patch as I haven't added OS/2 to anywhere else in the docs. My thinging has been that OS/2 is a 2nd tier platform, and I have kept an extensive port README file in the build directory (PC/os2emx) documenting port specific behaviour. The idea with the environment variable version was that it would be less "intrusive" a change from the user POV. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 04/10/06 08:09 Message: Logged In: YES user_id=21627 re 1) Currently, the usage of the stacksize attribute is depending on the definition of a THREAD_STACK_SIZE macro. I don't know where that comes from, but I guess whoever defines it knows what he is doing, so that the stacksize attribute is defined on such a system. re 2) I can accept that Python enforces a minimum above PTHREAD_STACK_MIN; it shouldn't be possible to set the stack size below PTHREAD_STACK_MIN, since that *will* fail when a thread is created. -1 for an environment variable version. What problem would that solve? If this patch gets implemented, applications can define their own environment variables if they think it helps, and users/admins can put something in sitecustomize.py if they think there should be an environment variable controlling the stack size for all Python applications on the system. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 04/10/06 07:45 Message: Logged In: YES user_id=250749 1) wrt _POSIX_THREAD_ATTR_STACKSIZE, I'll look at that (though I note its absence from the existing code...) 2) PTHREAD_STACK_MIN on FreeBSD is 1k, which seemed grossly inadequate for Python (my impression is that 20-32k is a fairly safe minimum for Python). In principle I don't have a problem with relying on PTHREAD_STACK_MIN, except for trying to play it safe. Any further thoughts on this? I'm also putting together an environment variable only version of the patch, with a view to getting that in first, and reworking this patch to work on top of that. Thanks for the comments. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 04/10/06 06:41 Message: Logged In: YES user_id=21627 Usage of pthread_attr_setstacksize should be conditional on the definition of _POSIX_THREAD_ATTR_STACKSIZE, according to POSIX. Errors from pthread_attr_setstacksize should be reported (POSIX lists EINVAL as a possible error). I think PTHREAD_STACK_MIN should be considered. The documentation should list availibility of the feature, currently Win32, OS/2, and POSIX threads (with the TSS option, to be precise). If some platforms have specific additional requirements on the possible values (eg. must be a multiple of the page size), these should be documented, as well. Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 03/22/06 00:28 Message: Logged In: YES user_id=250749 Thanks for the comments. As implemented, the function is both a getter and (optionally) a setter which makes attempting to use a "get"/"set" prefix awkward. I chose this approach to make it a little simpler to support temporary changes. I did consider using a module attribute/variable, but it is slightly more unwieldy for this case: old_size = thread.stack_size(new_size) ... thread.stack_size(old_size) vs old_size = thread.stack_size thread.stack_size = new_size ... thread.stack_size = old_size or (using get/set accessors) old_size = thread.get_stacksize() thread.set_stacksize(new_size) ... thread.set_stacksize(old_size) I think an argument can be made for passing on the "get"/"set" naming consistency based on the guidelines in PEP 8. While I have a preference for what I've implemented, I'm more interested in getting the functionality in than debating its decor. If there's a strong view about these issues, I'm prepared to revise the patch accordingly. I don't believe that the functionality belongs anywhere else than the thread module, except possibly shadowing it in the threading module, as it is highly specific to thread support. The sys module seems more appropriate for general knobs, and only for specific knobs when there is no other choice IMO. Doing it outside the thread module also complicates the implementation, which I was trying to keep as simple as I could. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 03/20/06 05:58 Message: Logged In: YES user_id=55188 I'm all for this! The FreeBSD port have maintained a local patch to bump THREAD_STACK_SIZE. The patch will lighten FreeBSD users' burden around thread stack size. BTW, the naming, "thread.stack_size" seems to miss a verb while all the other functions on the thread module have it. How about set_stack_size() or set_stacksize()? Or, how about in sys module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454481&group_id=5470 From noreply at sourceforge.net Thu Jun 29 17:55:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 08:55:36 -0700 Subject: [Patches] [ python-Patches-1479219 ] ColorDelegator - Several bug fixes Message-ID: Patches item #1479219, was opened at 2006-04-30 10:48 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Kurt B. Kaiser (kbk) Summary: ColorDelegator - Several bug fixes Initial Comment: This patch fixes the following bugs in the Bug Tracker: [ 1325071 ] "as" keyword sometimes highlighted in strings This patch fixes the following undocumented bugs: * "as" keyword colored as a keyword even in comments on the 'import' line * Comments such as "#False identity", which start with a keyword immediatly after the '#' character, aren't colored as comments. * In unicode string literals (e.g. u"bob"), the preceding 'u' character isn't colored as part of the string. But the preceding 'r' of raw string literals is. I have only added/fixed minor details, no logic changes. ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2006-06-29 18:55 Message: Logged In: YES user_id=1330769 Replaced patch file: Fixed a minor bug caused by faulty use of the "and/or trick". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&group_id=5470 From noreply at sourceforge.net Thu Jun 29 18:06:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 09:06:23 -0700 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 07:40 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-06-29 19:06 Message: Logged In: YES user_id=1330769 This module is simple and works, but IDLE already has an auto-completion module! It is in Python's SVN and will be part of Python2.5. The module posted here is extremely na??ve and lacking compared to the existing auto-completion module. For example, it catches events instead of the Text widget and inserts characters directly into it to compensate for this. The MultiCall module on which the existing auto-completion module is built it a much better solution. ---------------------------------------------------------------------- Comment By: Jerry (jerrykingking) Date: 2005-11-21 13:28 Message: Logged In: YES user_id=1382613 AutoComplete.py is a IDLE module that extends Listbox and Scrollbar controls with autocompletion capabilities. Although the IDLE provides rich foundation for Python application developers, it doesn't provide any built-in autocompletion support! AutoComplete module fills the gap by bringing autocompletion capabilities to IDLE. Users of IDLE can enjoy the same autocomplete functionality they already know from Pythonwin. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 08:58 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 08:57 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Thu Jun 29 19:38:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 10:38:16 -0700 Subject: [Patches] [ python-Patches-1513699 ] docs for xturtle.py Message-ID: Patches item #1513699, was opened at 2006-06-28 02:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513699&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: docs for xturtle.py Initial Comment: This is a compiled docfile for xturtle.py. Methods, (and functions) are grouped in functional groups (sections). Some information on the structure of the module is added. (At present more information as well as example scripts can be found at http://ada.rg16.asn-wien.ac.at/~python/xturtle) Regards, Gregor Lingl ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-29 19:38 Message: Logged In: YES user_id=21627 You forgot to include the file. I'm closing this report; please attach/include the documentation with 1513695 instead; SF does allow attached multiple files to a report (just not in a single interaction). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513699&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:07:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:07:41 -0700 Subject: [Patches] [ python-Patches-1512942 ] Improves an error message from setattr Message-ID: Patches item #1512942, was opened at 2006-06-26 15:47 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None >Priority: 3 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Improves an error message from setattr Initial Comment: Fixes Bugs item #1506776 ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-29 14:07 Message: Logged In: YES user_id=835142 I did not think of the that case. It looks like there is no easy way to distinguish the slots and no slots case in PyObject_GenericSetAttr. I think the proper fix will involve not filling tp_setattro with PyObject_GenericSetAttr in the presence of slots, but use a function that is optimized for that case. Can anyone suggest a simpler fix? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-28 06:36 Message: Logged In: YES user_id=4771 The error message can still be wrong. For example, in the following situation: class X(object): __slots__ = ['a'] X().b = 5 Then the original message -- no attribute 'b' -- was correct. With this patch Python now wrongly tells you that 'X' object has only read-only attributes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:16:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:16:46 -0700 Subject: [Patches] [ python-Patches-1513695 ] new turtle module Message-ID: Patches item #1513695, was opened at 2006-06-28 02:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: new turtle module Initial Comment: The file, at present named xturtle.py is a reimplementation of turtle.py with additional features, among them: -Better animation of the turtle movements, especially of turning the turtle. So the turtles can more easily be used as a visual feedback instrument by the (beginning) programmer. -Different turtle shapes, gif-images as turtle shapes, user defined and user controllable turtle shapes, among them compound (multicolored) shapes. -Fine control over turtle movement and screen updates via delay(), and enhanced tracer() and speed(), update() methods. -Aliases for the most commonly used commands, like fd for forward etc. ... -Some simple commands/methods for creating event driven programs (mouse-, key-, timer-events). Especially useful for programming simple games. -A scrollable Canvas class. The scrollable Canvas can be extended interactively as needed while playing around with the turtle(s) (e. g. to follow some escaped turtle). -Commands for controlling background color or background image. detailed documentation is in the docstrings (similar to the last version of turtle.py) which copmrise approx. 50% of the filesize. xturtle.py is widely backward compatible to turtle.py (i. e. except the appearance of the turtle(s) and their animation) I propose to replace turtle.py by xturtle.py Separate Documentation is available as a text file reassembled and enhanced from the docstring. I'll supply this in a separate patch (as it seems impossible here to attach 2 files) Regards, Gregor Lingl ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-29 20:16 Message: Logged In: YES user_id=21627 A number of remarks: 1. would you like to see the demo applications included as well? They could go somewhere into Demo. If so, please prepare the patch as a single tar/zip file that unpacks on top of a Python source tree. 2. The doc string refers to the module as xturtle, and says it replaces turtle. If the module becomes turtle, this remark becomes self-referential. Please update the doc string accordingly. 3. Somebody should investigate the rationale for re-exporting math in the current turtle.py. If that rationale is still valid, the new module should comply. 4. The module should grow an __all__ attribute. 5. _Vec does not appear to be a general vector class, but be restricted to 2D cartesian coordinates. It should be renamed. Perhaps to "Point?" 6. Try to follow PEP 8, in particular, drop camelCase for method names. 7. Avoid passive voice for doc strings; use active voice instead (e.g. addshape: "Adds a turtle" -> "Add a turtle") 8. What happens to the n= argument of clear()? 9. What is the purpose/status of checkargs? Do you want to keep it or drop it? 10. There are some German doc strings left (e.g. _rotate). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513695&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:26:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:26:14 -0700 Subject: [Patches] [ python-Patches-1514543 ] mailbox (Maildir): avoid losing messages on name clash Message-ID: Patches item #1514543, was opened at 2006-06-29 19: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=1514543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox (Maildir): avoid losing messages on name clash Initial Comment: The Maildir specification says that messages should be moved into the "new" directory using link()/unlink(), not rename(). This isn't for compatibility with ancient Unixes, but to avoid overwriting an existing message if the "unique" name turns out not to be unique after all. (In the current implementation this can happen if the system clock only has whole-second resolution and deliveries are being done in subprocesses, or the clock has been adjusted backwards, or two machines have the same hostname.) Similarly, the file in "tmp" should be created O_EXCL. This patch implements these requirements, falling back to rename() if link() is unavailable (where on Windows at least, it's supposed to fail if the destination exists), and raising ExternalClashError when the link/rename fails due to the name already being taken in "new". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 From noreply at sourceforge.net Thu Jun 29 20:27:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 11:27:16 -0700 Subject: [Patches] [ python-Patches-1514544 ] mailbox: use fsync() to ensure data is really on disk Message-ID: Patches item #1514544, was opened at 2006-06-29 19: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=1514544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: use fsync() to ensure data is really on disk Initial Comment: The mailbox module currently does nothing to ensure messages/indexes are physically on disk when the flush() method returns or message files are closed. This patch adds functions _sync_flush and _sync_close to flush and fsync() a file object, and in the latter case close it afterwards. _sync_close is then used where needed throughout the code. (For various reasons the current implementation only ever requires a sync immediately before closing a file, but _sync_flush is provided for future use.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:36:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:36:27 -0700 Subject: [Patches] [ python-Patches-1514737 ] proposal for a new circle method Message-ID: Patches item #1514737, was opened at 2006-06-29 22:36 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=1514737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: proposal for a new circle method Initial Comment: The attached file contains the proposal for (1) a new circle method (here called circle2) (2) a new circle function (also called circle2) Moreover it contains a testscript showing the respective3 filling behaviour. Visually they behave differently and it may well be a point of discussion if this replacement schould be made. circle2 has correct filling behaviour and doesn't show the strange 'not drawing feature' after a radians() call. All the other problems with radians()/degrees() remain. (see #1514685) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 From noreply at sourceforge.net Fri Jun 30 00:37:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 15:37:20 -0700 Subject: [Patches] [ python-Patches-1514737 ] proposal for a new circle method Message-ID: Patches item #1514737, was opened at 2006-06-29 22:36 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) >Assigned to: Martin v. L??wis (loewis) Summary: proposal for a new circle method Initial Comment: The attached file contains the proposal for (1) a new circle method (here called circle2) (2) a new circle function (also called circle2) Moreover it contains a testscript showing the respective3 filling behaviour. Visually they behave differently and it may well be a point of discussion if this replacement schould be made. circle2 has correct filling behaviour and doesn't show the strange 'not drawing feature' after a radians() call. All the other problems with radians()/degrees() remain. (see #1514685) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 From noreply at sourceforge.net Fri Jun 30 06:06:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 21:06:43 -0700 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 21:27 Message generated for change (Comment added) made by illume You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Tim Peters (tim_one) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 04:06 Message: Logged In: YES user_id=2042 Note, that this patch doesn't fix all memory leaks of this type. For example, this code below doesn't release all the memory after it is run. It starts at about 3MB, goes up to about 56MB and then only drops to 50MB. AFAIK restarting python processes is still needed to reduce memory usage for certain types of processes. 

import random
import os

def fill(map):
    random.seed(0)
    for i in xrange(300000):
        k1 = (random.randrange(100),
              random.randrange(100),
              random.randrange(100))
        k2 = random.randrange(100)
        if k1 in map:
            d = map[k1]
        else:
            d = dict()
        d[k2] = d.get(k2, 0) + 1
        map[k1] = d

if __name__ == "__main__":
    os.system('ps v')
    d = dict()
    fill(d)
    print "-"* 50
    print "\n" * 3
    os.system('ps v')
    del d

    import gc
    gc.collect()

    print "-"* 50
    print "\n" * 3
    os.system('ps v')
---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-16 01:17 Message: Logged In: YES user_id=31435 The tim-obmalloc branch was merged to the trunk (for Python 2.5a1) in revision 43059. Thank you again for your hard work and patience, Evan! ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2006-02-23 14:29 Message: Logged In: YES user_id=539295 Great news! If you need any assistance, I would be more than happy to help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-02-23 01:25 Message: Logged In: YES user_id=31435 The patch here is out of date, but that's OK. I created branch tim-obmalloc, with a working version of the patch, extensively reformatted to Python's C style, and with some minor changes to squash compiler warnings. I plan to finish this during PyCon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-05 22:43 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-05-10 04:31 Message: Logged In: YES user_id=539295 Whoops! I uploaded a "fixed" version a while ago, but I guess I didn't update the comments. The patch currently attached to this is the most up- to-date version. Sorry about that. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-19 14:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 22:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Fri Jun 30 08:02:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 23:02:38 -0700 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 21:27 Message generated for change (Comment added) made by illume You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Tim Peters (tim_one) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 06:02 Message: Logged In: YES user_id=2042 I have done some more tests... and it seems that dictionaries do not release as much memory as lists do. Here is a modification of the last example posted. If you only let fill2() run almost all the memory is freed. fill2() uses lists. However if you let the others which use dicts run not all of the memory is freed. The processes are still 38MB when the data is del'ed. It is still much better than python2.4, however I think something fishy must be going on with dicts. 

import random
import os

def fill_this_one_doesnot_free_much_at_all(map):
    random.seed(0)
    for i in xrange(300000):
        k1 = (random.randrange(100),
              random.randrange(100),
              random.randrange(100))
        k2 = random.randrange(100)
        if k1 in map:
            d = map[k1]
        else:
            d = dict()
        d[k2] = d.get(k2, 0) + 1
        map[k1] = d


def fill(map):
    random.seed(0)
    for i in xrange(3000000):
        map[i] = "asdf"


class Obj:
    def __init__( self ):
        self.dumb = "hello"


def fill2(map):
    a = []
    for i in xrange(300000):
        o = Obj()
        a.append(o)
    return a


if __name__ == "__main__":
    import time
    import gc

    os.system('ps v | grep memtest')
    d = dict()
    a = fill2(d)
    #a2 = fill(d)
    a2 = fill_this_one_doesnot_free_much_at_all(d)
    print "-"* 50
    print "\n" * 3
    os.system('ps v | grep memtest')
    del d
    del a

    gc.collect()

    time.sleep(2)
    for x in xrange(100000):
        pass
    print "-"* 50
    print "\n" * 3
    os.system('ps v | grep memtest')
---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 04:06 Message: Logged In: YES user_id=2042 Note, that this patch doesn't fix all memory leaks of this type. For example, this code below doesn't release all the memory after it is run. It starts at about 3MB, goes up to about 56MB and then only drops to 50MB. AFAIK restarting python processes is still needed to reduce memory usage for certain types of processes. 

import random
import os

def fill(map):
    random.seed(0)
    for i in xrange(300000):
        k1 = (random.randrange(100),
              random.randrange(100),
              random.randrange(100))
        k2 = random.randrange(100)
        if k1 in map:
            d = map[k1]
        else:
            d = dict()
        d[k2] = d.get(k2, 0) + 1
        map[k1] = d

if __name__ == "__main__":
    os.system('ps v')
    d = dict()
    fill(d)
    print "-"* 50
    print "\n" * 3
    os.system('ps v')
    del d

    import gc
    gc.collect()

    print "-"* 50
    print "\n" * 3
    os.system('ps v')
---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-16 01:17 Message: Logged In: YES user_id=31435 The tim-obmalloc branch was merged to the trunk (for Python 2.5a1) in revision 43059. Thank you again for your hard work and patience, Evan! ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2006-02-23 14:29 Message: Logged In: YES user_id=539295 Great news! If you need any assistance, I would be more than happy to help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-02-23 01:25 Message: Logged In: YES user_id=31435 The patch here is out of date, but that's OK. I created branch tim-obmalloc, with a working version of the patch, extensively reformatted to Python's C style, and with some minor changes to squash compiler warnings. I plan to finish this during PyCon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-05 22:43 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-05-10 04:31 Message: Logged In: YES user_id=539295 Whoops! I uploaded a "fixed" version a while ago, but I guess I didn't update the comments. The patch currently attached to this is the most up- to-date version. Sorry about that. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-19 14:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 22:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Fri Jun 30 08:17:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 23:17:06 -0700 Subject: [Patches] [ python-Patches-1123430 ] Python memory allocator: Free memory Message-ID: Patches item #1123430, was opened at 2005-02-15 16:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Evan Jones (vulturex) Assigned to: Tim Peters (tim_one) Summary: Python memory allocator: Free memory Initial Comment: This is the second version of my Python memory allocator patch. The first version was discussed on the python-dev mailing list here: http://mail.python.org/pipermail/python-dev/2005-January/ 051255.html This patch enables Python to actually return memory to the system. The current version's memory usage will only grow. This version maintains the same backwards compatability guarantees as the previous version: Calling PyObject_Free with a pointer that was returned by malloc() while NOT holding the GIL will work, and will not corrupt the state of the memory allocator. The patch modifies obmalloc.c. If it is accepted, other modifications to that file are required. In particular, I have not yet updated the WITH_MEMORY_LIMITS implementation, nor have I looked closely at the PYMALLOC_DEBUG code to see what changes (if any) are required. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-06-30 02:17 Message: Logged In: YES user_id=31435 As the NEWS entry says, """ Patch #1123430: Python's small-object allocator now returns an arena to the system ``free()`` when all memory within an arena becomes unused again. Prior to Python 2.5, arenas (256KB chunks of memory) were never freed. Some applications will see a drop in virtual memory size now, especially long-running applications that, from time to time, temporarily use a large number of small objects. Note that when Python returns an arena to the platform C's ``free()``, there's no guarantee that the platform C library will in turn return that memory to the operating system. The effect of the patch is to stop making that impossible, and in tests it appears to be effective at least on Microsoft C and gcc-based systems. """ An instrumented debug build of current trunk showed that Python eventually returned 472 of 544 allocated arenas to the platform free() in your program, leaving 72 still allocated when Python shut down. The latter is due to fragmentation, and there will never be "a cure" for that since CPython guarantees never to move objects. The arena highwater mark was 240 arenas, which is what Python would have held on to forever before the patch. A large part of the relatively disappointing result we see here is due to that the tuple implementation maintains its own free lists too: it never returns a few thousand of the tuple objects to obmalloc before Python shuts down, and that in turn keeps all the arenas from which those tuple objects were originally obtained alive until Python shuts down. There's nothing obmalloc or gcmodule can do about that, and the tuple free lists are _likely_ an important optimization in real applications. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 02:02 Message: Logged In: YES user_id=2042 I have done some more tests... and it seems that dictionaries do not release as much memory as lists do. Here is a modification of the last example posted. If you only let fill2() run almost all the memory is freed. fill2() uses lists. However if you let the others which use dicts run not all of the memory is freed. The processes are still 38MB when the data is del'ed. It is still much better than python2.4, however I think something fishy must be going on with dicts. 

import random
import os

def fill_this_one_doesnot_free_much_at_all(map):
    random.seed(0)
    for i in xrange(300000):
        k1 = (random.randrange(100),
              random.randrange(100),
              random.randrange(100))
        k2 = random.randrange(100)
        if k1 in map:
            d = map[k1]
        else:
            d = dict()
        d[k2] = d.get(k2, 0) + 1
        map[k1] = d


def fill(map):
    random.seed(0)
    for i in xrange(3000000):
        map[i] = "asdf"


class Obj:
    def __init__( self ):
        self.dumb = "hello"


def fill2(map):
    a = []
    for i in xrange(300000):
        o = Obj()
        a.append(o)
    return a


if __name__ == "__main__":
    import time
    import gc

    os.system('ps v | grep memtest')
    d = dict()
    a = fill2(d)
    #a2 = fill(d)
    a2 = fill_this_one_doesnot_free_much_at_all(d)
    print "-"* 50
    print "\n" * 3
    os.system('ps v | grep memtest')
    del d
    del a

    gc.collect()

    time.sleep(2)
    for x in xrange(100000):
        pass
    print "-"* 50
    print "\n" * 3
    os.system('ps v | grep memtest')
---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 00:06 Message: Logged In: YES user_id=2042 Note, that this patch doesn't fix all memory leaks of this type. For example, this code below doesn't release all the memory after it is run. It starts at about 3MB, goes up to about 56MB and then only drops to 50MB. AFAIK restarting python processes is still needed to reduce memory usage for certain types of processes. 

import random
import os

def fill(map):
    random.seed(0)
    for i in xrange(300000):
        k1 = (random.randrange(100),
              random.randrange(100),
              random.randrange(100))
        k2 = random.randrange(100)
        if k1 in map:
            d = map[k1]
        else:
            d = dict()
        d[k2] = d.get(k2, 0) + 1
        map[k1] = d

if __name__ == "__main__":
    os.system('ps v')
    d = dict()
    fill(d)
    print "-"* 50
    print "\n" * 3
    os.system('ps v')
    del d

    import gc
    gc.collect()

    print "-"* 50
    print "\n" * 3
    os.system('ps v')
---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-15 20:17 Message: Logged In: YES user_id=31435 The tim-obmalloc branch was merged to the trunk (for Python 2.5a1) in revision 43059. Thank you again for your hard work and patience, Evan! ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2006-02-23 09:29 Message: Logged In: YES user_id=539295 Great news! If you need any assistance, I would be more than happy to help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-02-22 20:25 Message: Logged In: YES user_id=31435 The patch here is out of date, but that's OK. I created branch tim-obmalloc, with a working version of the patch, extensively reformatted to Python's C style, and with some minor changes to squash compiler warnings. I plan to finish this during PyCon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-05 18:43 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-05-10 00:31 Message: Logged In: YES user_id=539295 Whoops! I uploaded a "fixed" version a while ago, but I guess I didn't update the comments. The patch currently attached to this is the most up- to-date version. Sorry about that. ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-19 09:07 Message: Logged In: YES user_id=539295 As per the discussion on python-dev, I've removed the concurrency hack. The routines in obmalloc.c now *must* be called while holding the GIL, even if the pointer was allocated with malloc(). I also finally fixed the PYMALLOC_DEBUG routines, so I believe this patch is now "complete." ---------------------------------------------------------------------- Comment By: Evan Jones (vulturex) Date: 2005-02-18 17:08 Message: Logged In: YES user_id=539295 Please ignore this patch for the moment: I'm in the process of making some fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1123430&group_id=5470 From noreply at sourceforge.net Fri Jun 30 08:22:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 23:22:23 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 09:17 Message generated for change (Comment added) made by illume You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 06:22 Message: Logged In: YES user_id=2042 -1 for killing mingw compatibility by using VC8. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-06-22 12:01 Message: Logged In: YES user_id=113328 Please note: 1. Prior to the existence of the free Toolkit compiler, there was no supported method for building Python with a free compiler. It's sad (and annoying) that MS withdrew the compiler version just as support was added to Python, but it's just a reversion to the prior situation. 2. Building extensions is a separate issue, which is more related to the compiler used to build the official binaries than to what options exist for building Python for yourself. 3. If you want to build extensions for Python, you can use mingw (gcc) as well as MSVC. This has been supported for a long time now. 4. Mingw does not currently support linking with msvcr80.dll, so if the official Python build moves to VC8, we will lose the option of building extensions with mingw. Therefore, I see no advantage to switching the official builds to VC8, in terms of extension building. You gain VC 2005 Express as an option, but lose mingw. As mingw is a long-established option, you in effect lose because you've gone from a well-tested option to a new, relatively untried one. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-22 11:39 Message: Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Fri Jun 30 08:27:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Jun 2006 23:27:51 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-16 01:15 Message generated for change (Comment added) made by illume You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 06:27 Message: Logged In: YES user_id=2042 The author said that the patch is expected to reduce memory. If this is true, then the patch has a good reason to be applied. Another reason is maintainability. By removing the set like functionality which is already implemented in the setobject. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 06:44 Message: Logged In: YES user_id=21627 I don't think "it's natural to do it" is a convincing object reason to change a running system. A change should address correctness, efficiency, maintainability, functionality (features), legal issues, etc. I can't see any of this in this patch, so I'm -1. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-17 00:52 Message: Logged In: YES user_id=835142 Rationale: The container of interned strings logically a set. Current implementation that uses a dictionary with the same keys and values is clearly an artificial implementation of a set necessary in earlier versions of Python. With a proper C implementation of sets available, it is natural to use it to store interned strings. Since set and dict objects use the same lookup algorithm, this patch is not expected to affect performance and pybench does not show any difference. Since a large set is using half of the memory of the equivalent dict, this patch is expected to reduce interpretor memory usage. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 21:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 12:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 05:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 03:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 30 12:19:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 03:19:28 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 09:17 Message generated for change (Comment added) made by peterschwalm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-30 10:19 Message: Logged In: YES user_id=1543425 When will mingw move to msvcrt80.dll? ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 06:22 Message: Logged In: YES user_id=2042 -1 for killing mingw compatibility by using VC8. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-06-22 12:01 Message: Logged In: YES user_id=113328 Please note: 1. Prior to the existence of the free Toolkit compiler, there was no supported method for building Python with a free compiler. It's sad (and annoying) that MS withdrew the compiler version just as support was added to Python, but it's just a reversion to the prior situation. 2. Building extensions is a separate issue, which is more related to the compiler used to build the official binaries than to what options exist for building Python for yourself. 3. If you want to build extensions for Python, you can use mingw (gcc) as well as MSVC. This has been supported for a long time now. 4. Mingw does not currently support linking with msvcr80.dll, so if the official Python build moves to VC8, we will lose the option of building extensions with mingw. Therefore, I see no advantage to switching the official builds to VC8, in terms of extension building. You gain VC 2005 Express as an option, but lose mingw. As mingw is a long-established option, you in effect lose because you've gone from a well-tested option to a new, relatively untried one. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-22 11:39 Message: Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Fri Jun 30 12:49:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 03:49:00 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 10:17 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-06-30 11:49 Message: Logged In: YES user_id=113328 mingw-runtime 3.10 (released a few days ago) supports msvcr80. Python (distutils) would need a patch to supply the necessary flags when it detects that python.exe is using msvcr80 (that's non-trivial, as you need to know, and hard-code, the MSVC compiler version numbers :-(). As we're in feature-freeze for Python 2.5, this won't happen until 2.6, but I am happy to make a patch for 2.6 to support msvcr80 in distutils (assuming someone lets me know the relevant MSVC build numbers when I need them). By the way, this thread is irrelevant to the actual patch, which is merely a doc patch... ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-30 11:19 Message: Logged In: YES user_id=1543425 When will mingw move to msvcrt80.dll? ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 07:22 Message: Logged In: YES user_id=2042 -1 for killing mingw compatibility by using VC8. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-06-22 13:01 Message: Logged In: YES user_id=113328 Please note: 1. Prior to the existence of the free Toolkit compiler, there was no supported method for building Python with a free compiler. It's sad (and annoying) that MS withdrew the compiler version just as support was added to Python, but it's just a reversion to the prior situation. 2. Building extensions is a separate issue, which is more related to the compiler used to build the official binaries than to what options exist for building Python for yourself. 3. If you want to build extensions for Python, you can use mingw (gcc) as well as MSVC. This has been supported for a long time now. 4. Mingw does not currently support linking with msvcr80.dll, so if the official Python build moves to VC8, we will lose the option of building extensions with mingw. Therefore, I see no advantage to switching the official builds to VC8, in terms of extension building. You gain VC 2005 Express as an option, but lose mingw. As mingw is a long-established option, you in effect lose because you've gone from a well-tested option to a new, relatively untried one. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-22 12:39 Message: Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Fri Jun 30 13:36:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 04:36:06 -0700 Subject: [Patches] [ python-Patches-1504046 ] Rough documentation for xml.etree.ElementTree Message-ID: Patches item #1504046, was opened at 2006-06-10 18:30 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: Rough documentation for xml.etree.ElementTree Initial Comment: Here's a text version (based on the existing PythonDoc documentation). Feel free to grab it and convert it to Latex. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2006-06-30 13:36 Message: Logged In: YES user_id=147070 http://members.chello.at/engelbert.gruber/python/elementtree -docpy.tar.gz contains the modified (for docpy-writer) documentation and a translation into latex. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 21:30 Message: Logged In: YES user_id=3066 There's an open question on whether this should be documented as xml.etree or xmlcore.etree. With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused "xml" package insanity any further. Posted also to python-dev: http://mail.python.org/pipermail/python-dev/2006-June/065816.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 From noreply at sourceforge.net Fri Jun 30 17:55:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 08:55:21 -0700 Subject: [Patches] [ python-Patches-1509163 ] MS Toolkit Compiler no longer available Message-ID: Patches item #1509163, was opened at 2006-06-20 11:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L??wis (loewis) Summary: MS Toolkit Compiler no longer available Initial Comment: Microsoft have withdrawn the free Toolkit Compiler 2003. This patch to PCBuild\readme.txt updates the Python build documentation to reflect this fact. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 17:55 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as r47162. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-06-30 12:49 Message: Logged In: YES user_id=113328 mingw-runtime 3.10 (released a few days ago) supports msvcr80. Python (distutils) would need a patch to supply the necessary flags when it detects that python.exe is using msvcr80 (that's non-trivial, as you need to know, and hard-code, the MSVC compiler version numbers :-(). As we're in feature-freeze for Python 2.5, this won't happen until 2.6, but I am happy to make a patch for 2.6 to support msvcr80 in distutils (assuming someone lets me know the relevant MSVC build numbers when I need them). By the way, this thread is irrelevant to the actual patch, which is merely a doc patch... ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-30 12:19 Message: Logged In: YES user_id=1543425 When will mingw move to msvcrt80.dll? ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 08:22 Message: Logged In: YES user_id=2042 -1 for killing mingw compatibility by using VC8. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2006-06-22 14:01 Message: Logged In: YES user_id=113328 Please note: 1. Prior to the existence of the free Toolkit compiler, there was no supported method for building Python with a free compiler. It's sad (and annoying) that MS withdrew the compiler version just as support was added to Python, but it's just a reversion to the prior situation. 2. Building extensions is a separate issue, which is more related to the compiler used to build the official binaries than to what options exist for building Python for yourself. 3. If you want to build extensions for Python, you can use mingw (gcc) as well as MSVC. This has been supported for a long time now. 4. Mingw does not currently support linking with msvcr80.dll, so if the official Python build moves to VC8, we will lose the option of building extensions with mingw. Therefore, I see no advantage to switching the official builds to VC8, in terms of extension building. You gain VC 2005 Express as an option, but lose mingw. As mingw is a long-established option, you in effect lose because you've gone from a well-tested option to a new, relatively untried one. ---------------------------------------------------------------------- Comment By: Peter Schwalm (peterschwalm) Date: 2006-06-22 13:39 Message: Logged In: YES user_id=1543425 If I interpret the bug tracker correctly, the 2.5 team is not about to change the "normal" build process for windows, because they refer to a special pcbuild8 directory for building with Visual Studio express. Of course if building python 2.5 with VC8 is possible, this is an improvement. But the problem is: the "normal" build process of a python distribution is also integrated into the setup modules for building extensions (. pyd-Files). And that means: anyone who wants to build a c- language extension, has to - either still have the withdrawn MS compiler - or build a custom version of python 2.5 (with pcbuild 8 ). And what about distributing the .pyd-Files if she/he uses alternative 2? One would have to distribute the custom python version too. My conclusion: it would be very helpful if the windows version of python 2. 5 were build with the vc8 compiler! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1509163&group_id=5470 From noreply at sourceforge.net Fri Jun 30 18:01:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 09:01:16 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-16 03:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 18:01 Message: Logged In: YES user_id=21627 Ok, memory reduction would be a valid reason. How much memory is being preserved (say, for an empty program, or for an IDLE run)? I don't see the improved maintainability. Interning is inherently *not* a set operation, it's a dictionary operation: You are given a string, and need to return its interned version. That's a table lookup. In fact, the set API had to be changed (to add _PySet_InternString) to add a lookup operation. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 08:27 Message: Logged In: YES user_id=2042 The author said that the patch is expected to reduce memory. If this is true, then the patch has a good reason to be applied. Another reason is maintainability. By removing the set like functionality which is already implemented in the setobject. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 08:44 Message: Logged In: YES user_id=21627 I don't think "it's natural to do it" is a convincing object reason to change a running system. A change should address correctness, efficiency, maintainability, functionality (features), legal issues, etc. I can't see any of this in this patch, so I'm -1. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-17 02:52 Message: Logged In: YES user_id=835142 Rationale: The container of interned strings logically a set. Current implementation that uses a dictionary with the same keys and values is clearly an artificial implementation of a set necessary in earlier versions of Python. With a proper C implementation of sets available, it is natural to use it to store interned strings. Since set and dict objects use the same lookup algorithm, this patch is not expected to affect performance and pybench does not show any difference. Since a large set is using half of the memory of the equivalent dict, this patch is expected to reduce interpretor memory usage. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 23:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 14:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 07:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 05:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 30 18:44:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 09:44:12 -0700 Subject: [Patches] [ python-Patches-1514737 ] proposal for a new circle method Message-ID: Patches item #1514737, was opened at 2006-06-30 00:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: proposal for a new circle method Initial Comment: The attached file contains the proposal for (1) a new circle method (here called circle2) (2) a new circle function (also called circle2) Moreover it contains a testscript showing the respective3 filling behaviour. Visually they behave differently and it may well be a point of discussion if this replacement schould be made. circle2 has correct filling behaviour and doesn't show the strange 'not drawing feature' after a radians() call. All the other problems with radians()/degrees() remain. (see #1514685) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 18:44 Message: Logged In: YES user_id=21627 New methods are not acceptable for Python 2.5 at this point. Can you think of a reason why this should *not* become the circle method? I understand that this fixes a bug, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 From noreply at sourceforge.net Fri Jun 30 21:23:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 12:23:46 -0700 Subject: [Patches] [ python-Patches-1514737 ] proposal for a new circle method Message-ID: Patches item #1514737, was opened at 2006-06-29 22:36 Message generated for change (Comment added) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: proposal for a new circle method Initial Comment: The attached file contains the proposal for (1) a new circle method (here called circle2) (2) a new circle function (also called circle2) Moreover it contains a testscript showing the respective3 filling behaviour. Visually they behave differently and it may well be a point of discussion if this replacement schould be made. circle2 has correct filling behaviour and doesn't show the strange 'not drawing feature' after a radians() call. All the other problems with radians()/degrees() remain. (see #1514685) ---------------------------------------------------------------------- >Comment By: Lingl (gregorlingl) Date: 2006-06-30 19:23 Message: Logged In: YES user_id=1547199 A misinterpretation: I think it *should* become the circle method. (It were a weird idea to introduce a circle2 method anyway). I only named it circle2 for now and test purposes in order to compare the behaviours of the two. If you are content with the patch, replace circle by circle2 'as circle' - if not leave circle2 out and let everything as is. Imho the the points to think about are: (i) is the polygon approximation ok? I think, my testscript gives a positive answer: the polygons are visually nearly indistiguishable from the canvas circle items. (Moreover I tested it with radiuses in the range from 1 to 200 successfully) (ii)that the new method relies on the forward method and thus circles are drawn much slower. For me this is quite ok. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 16:44 Message: Logged In: YES user_id=21627 New methods are not acceptable for Python 2.5 at this point. Can you think of a reason why this should *not* become the circle method? I understand that this fixes a bug, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 From noreply at sourceforge.net Fri Jun 30 22:33:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 13:33:47 -0700 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-15 21:15 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-30 16:33 Message: Logged In: YES user_id=835142 I did not measure the memory usage and I don't think such measurement will yield a compelling reason for the change. I suggested that a set is half of a dict, but that was wrong because dictentry is only 1.5 times larger than setentry because of the cached hash and depending on the size of the internet strings, large portion of the memory will be used by the string object themselves and that will not change with the patch. My primary reason is the simplicity (you can call it maintainability). I find the off by two reference count in the current dict based implementation rather unnatural and I think the dict that maps keys to themselves is a set. I disagree with Martin. I think interning is a set operation and it is unfortunate that set API does not support it directly. I guess the current view is that set is not a container. Although you can put things in a set and check if they are there, there is no API to get the things back. I would really like to see set C API to provide all the functionality of a dict with value=key, but it is also possible that I complitely misunderstood the need of the set object in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 12:01 Message: Logged In: YES user_id=21627 Ok, memory reduction would be a valid reason. How much memory is being preserved (say, for an empty program, or for an IDLE run)? I don't see the improved maintainability. Interning is inherently *not* a set operation, it's a dictionary operation: You are given a string, and need to return its interned version. That's a table lookup. In fact, the set API had to be changed (to add _PySet_InternString) to add a lookup operation. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 02:27 Message: Logged In: YES user_id=2042 The author said that the patch is expected to reduce memory. If this is true, then the patch has a good reason to be applied. Another reason is maintainability. By removing the set like functionality which is already implemented in the setobject. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 02:44 Message: Logged In: YES user_id=21627 I don't think "it's natural to do it" is a convincing object reason to change a running system. A change should address correctness, efficiency, maintainability, functionality (features), legal issues, etc. I can't see any of this in this patch, so I'm -1. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 20:52 Message: Logged In: YES user_id=835142 Rationale: The container of interned strings logically a set. Current implementation that uses a dictionary with the same keys and values is clearly an artificial implementation of a set necessary in earlier versions of Python. With a proper C implementation of sets available, it is natural to use it to store interned strings. Since set and dict objects use the same lookup algorithm, this patch is not expected to affect performance and pybench does not show any difference. Since a large set is using half of the memory of the equivalent dict, this patch is expected to reduce interpretor memory usage. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 17:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 08:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-16 01:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-15 23:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Fri Jun 30 23:49:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 14:49:09 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 17:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 From noreply at sourceforge.net Fri Jun 30 23:52:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 14:52:09 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 17:49 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:52 Message: Logged In: YES user_id=764593 In order to fix it, I also broke out some repeated code into a subfunction, and switched some logic to a more modern idiom -- these parts *could* be separated if need be, but I won't be able to do it this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 From noreply at sourceforge.net Fri Jun 30 23:53:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 14:53:47 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 17:49 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:53 Message: Logged In: YES user_id=764593 For misc/news, I suggest something like "Fixed an obscure traceback regression when (deprecated) strings are raised." ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:52 Message: Logged In: YES user_id=764593 In order to fix it, I also broke out some repeated code into a subfunction, and switched some logic to a more modern idiom -- these parts *could* be separated if need be, but I won't be able to do it this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470