From noreply at sourceforge.net Fri Sep 1 00:44:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 15:44:36 -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 (Comment added) made by collinwinter 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. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-08-31 18:44 Message: Logged In: YES user_id=1344176 The patch has been updated to r51654. I'm not sure how well `svn diff` handles removed files, so you might have to `svn rm` Lib/sets.py, Lib/test/test_sets.py and Doc/lib/libsets.py manually. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 16:26 Message: Logged In: YES user_id=6380 This patch seems out of date -- can you refresh it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500611&group_id=5470 From noreply at sourceforge.net Fri Sep 1 01:15:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 16:15:04 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 03:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 18:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 14:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 17:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 14:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 12:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 03:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Fri Sep 1 01:16:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 16:16:40 -0700 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-18 20:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&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: 6 Submitted By: baus (cbaus) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Fri Sep 1 01:40:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 16:40:16 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 04:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 19:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 19:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 15:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 18:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 15:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 13:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 04:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Fri Sep 1 04:44:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 19:44:08 -0700 Subject: [Patches] [ python-Patches-1550272 ] Add a test suite for test_unittest Message-ID: Patches item #1550272, was opened at 2006-08-31 22: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=1550272&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: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add a test suite for test_unittest Initial Comment: This file replaces the current version Lib/test/test_unittest.py, which only contains a single test. The attached suite contains 128 tests for the mission-critical parts of unittest. A patch will follow shortly that fixes the bugs in unittest uncovered by this test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550272&group_id=5470 From noreply at sourceforge.net Fri Sep 1 04:44:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 19:44:52 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22: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=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 04:52:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 19:52:35 -0700 Subject: [Patches] [ python-Patches-1550272 ] Add a test suite for unittest Message-ID: Patches item #1550272, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550272&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: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) >Summary: Add a test suite for unittest Initial Comment: This file replaces the current version Lib/test/test_unittest.py, which only contains a single test. The attached suite contains 128 tests for the mission-critical parts of unittest. A patch will follow shortly that fixes the bugs in unittest uncovered by this test suite. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-08-31 22:52 Message: Logged In: YES user_id=1344176 That promised patch for unittest is #1550273. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550272&group_id=5470 From noreply at sourceforge.net Fri Sep 1 05:40:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 20:40:34 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-09-01 12:44 Message generated for change (Comment added) made by mumak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 13:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 06:19:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 21:19:32 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 06:39:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 21:39:23 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-09-01 12:44 Message generated for change (Comment added) made by mumak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 14:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 14:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 13:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 11:38:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 02:38:29 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-01 09:38 Message: Logged In: YES user_id=849994 Since you can put anything usable as an assignment target after the "for" of a listcomp, just renaming might be complicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 23:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 19:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 22:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 19:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 17:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 08:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Fri Sep 1 16:12:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 07:12:58 -0700 Subject: [Patches] [ python-Patches-1298813 ] sysmodule.c: realpath() is unsafe Message-ID: Patches item #1298813, was opened at 2005-09-22 16:54 Message generated for change (Comment added) made by spektrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&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: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sysmodule.c: realpath() is unsafe Initial Comment: realpath() will dereference all symlinks and resolve references to /./ and /../ (and so on). realpath accepts a source buffer and a destination buffer to copy the resolved path into. On certain systems PATH_MAX can be of arbitrary size, while the buffer passed in would be of a limiited size. There is no way to specify how long your "resolved" buffer is, therefore it is possible for one to overflow it. According to the man page: BUGS Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. glibc has certain extensions to avoid the buffer overflow. One option is to use canonicalize_file_name(), another is to specify a NULL as the second argument to realpath() (which essentially makes it behave like canonicalize_file_name(). Relevant documentation: info libc http://www.delorie.com/gnu/docs/glibc/libc_279.html Attached is a patch to use canonicalize_file_name if available. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-01 16:12 Message: Logged In: YES user_id=631694 if I may kindly remind you that this is a good time to implement some kind of a patch ;e) now that python 2.5 is nearing completion, and there's even a security advisory (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1542)... I have a working patch, applicable against 2.5c1, at http://users.suse.cz/~jmatejek/python-2.4.2-canonicalize2.patch (note the version number - the affected function didn't change since 2.4.2) ---------------------------------------------------------------------- Comment By: Peter Jones (pjones) Date: 2005-09-26 21:14 Message: Logged In: YES user_id=27350 ... but I see you meant the condition different than I parsed your explanation. Anyway, I'll get misa to upload a new patch once I've figured out what's going wrong entirely. ---------------------------------------------------------------------- Comment By: Peter Jones (pjones) Date: 2005-09-26 21:11 Message: Logged In: YES user_id=27350 There are actually a few more, very subtle problems with the new patch as well. I'll get misa to update a patch once I've worked through them. In general, regarding Red Hat's bz# 169046, there's no reason to do readlink() or realpath() if you've got canonicalize_file_name; it should provide both sets of functionality just fine. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-09-26 15:21 Message: Logged In: YES user_id=631694 there are two bugs in the patch: one is explained on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046 the other one is that with this patch, the value of n (length to be copied) stays zero all the time, so no copy occurs and various things happen. i have a patch, but don't know how to attach it - should i mail it to you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470 From noreply at sourceforge.net Fri Sep 1 18:40:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 09:40:25 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 23:08:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 14:08:14 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 23:19:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 14:19:00 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Sep 1 23:39:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 14:39:18 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-09-01 17:39 Message: Logged In: YES user_id=1344176 Jim: > (Is there something they could do to the TestCase() that > would start to fail if you wrap it in a TestSuite()? > Remember that they might have local standards saying "only > one test class per file" or something, so they might never > have gotten a real suite back in the past.) Off the top of my head: - TestSuite.run() requires a TestResult instance to be passed in where TestCase.run()'s result parameter is optional. - TestSuite doesn't have TestCase's shortDescription() or id() method. - Assignment to a TestCase instance's failureException attribute will affect the object's run() method, whereas the same assignment on a TestSuite will have no effect. IMHO none of these is significant enough to block that particular section of the patch. Remember that we're talking about a behaviour that's only triggered when the given name resolves to a callable and that callable returns a TestCase instance when invoked. I don't like the idea of keeping around long-standing minor bugs just because someone, somewhere might be using them. Can anyone produce a real example where someone is relying on this behaviour? I'll send a message to c.l.p on Monday and see if anyone in that wider audience can come up with concrete cases where these behaviours are mission-critical. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Sat Sep 2 00:15:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 15:15:30 -0700 Subject: [Patches] [ python-Patches-1550786 ] Ellipsis literal "..." Message-ID: Patches item #1550786, was opened at 2006-09-01 22: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=1550786&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: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: Ellipsis literal "..." Initial Comment: This patch makes ... a generally usable expression, as described in PEP 3100. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550786&group_id=5470 From noreply at sourceforge.net Sat Sep 2 00:31:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 15:31:13 -0700 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&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: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 18:31 Message: Logged In: YES user_id=764593 (Responding to the patch, not directly to the conversation) (1) (around lines 234) Do you really want two test cases to compare equal because they have the same name, even if that name is the default runTest? (2) Have you made sense of the UnboundMethodType case? As nearly as I can figure, the old behavior was to run call the test case with a method name (which by default tried to run it, using that string as a TestResult?!?, and then returned None), and the new behavior just wraps this None in a TestSuite. (3) After patch, the callable case has a "return test" which is dead code, because the other branches either raised or returned on their own. (4) Changing the raise from ValueError to TypeError would make sense if not for backwards compatibility. Could you use a custom error that inherits from both? Please don't let these comments get you down; this is code that needs cleaning. (The changes to not special-case jython and to not rewalk the mro are particularly good -- because they don't do anything, having them in the code is misleading.) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 17:39 Message: Logged In: YES user_id=1344176 Jim: > (Is there something they could do to the TestCase() that > would start to fail if you wrap it in a TestSuite()? > Remember that they might have local standards saying "only > one test class per file" or something, so they might never > have gotten a real suite back in the past.) Off the top of my head: - TestSuite.run() requires a TestResult instance to be passed in where TestCase.run()'s result parameter is optional. - TestSuite doesn't have TestCase's shortDescription() or id() method. - Assignment to a TestCase instance's failureException attribute will affect the object's run() method, whereas the same assignment on a TestSuite will have no effect. IMHO none of these is significant enough to block that particular section of the patch. Remember that we're talking about a behaviour that's only triggered when the given name resolves to a callable and that callable returns a TestCase instance when invoked. I don't like the idea of keeping around long-standing minor bugs just because someone, somewhere might be using them. Can anyone produce a real example where someone is relying on this behaviour? I'll send a message to c.l.p on Monday and see if anyone in that wider audience can come up with concrete cases where these behaviours are mission-critical. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Sat Sep 2 00:35:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 15:35:58 -0700 Subject: [Patches] [ python-Patches-1550800 ] make exec a function Message-ID: Patches item #1550800, was opened at 2006-09-01 22: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=1550800&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: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: make exec a function Initial Comment: Make exec a function, as described in PEP 3100. exec() now cannot modify the locals. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550800&group_id=5470 From noreply at sourceforge.net Sat Sep 2 06:39:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Sep 2006 21:39:14 -0700 Subject: [Patches] [ python-Patches-1550886 ] Fix decimal context management for 2.5 Message-ID: Patches item #1550886, was opened at 2006-09-02 14:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550886&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix decimal context management for 2.5 Initial Comment: Backport of the decimal module context management fixes already implemented on the trunk after discussion with Raymond. Also includes an appropriate update to the Python 2.5 What's New. Without this patch, the code, docstrings, standard library reference and What's New all say different things about the updated decimal context management API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550886&group_id=5470 From noreply at sourceforge.net Sun Sep 3 01:25:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 16:25:20 -0700 Subject: [Patches] [ python-Patches-1360200 ] bdist_rpm still can't handle dashes in versions Message-ID: Patches item #1360200, was opened at 2005-11-18 15:41 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360200&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.6 Status: Open Resolution: None Priority: 5 Submitted By: jared jennings (sarynx) Assigned to: Sean Reifschneider (jafo) Summary: bdist_rpm still can't handle dashes in versions Initial Comment: I tried to use Python 2.4.2 to create a bdist_rpm of setuptools, whose version string was 0.6a9dev-r41475. The distutils/command/bdist_rpm module's _make_spec_file method mangled the version to 0.6a9dev_r41475 (line 370). Then when the spec file was being built by rpmbuild, it looked for the sdist named setuptools-0.6a9dev_r41475.tar.gz, which didn't exist: it was called setuptools-0.6a9dev-r41475.tar.gz (note dash). So you have to mangle the version to make rpm happy - but you can't expect the sdist to have the mangled version as part of its name. I looked at the nightly Python source as of 17 Nov 2005 and saw that this bug still exists in the development version of Python. A patch is attached which fixed this bug for me. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2006-09-02 23:25 Message: Logged In: YES user_id=81797 This patch looks good to me. I checked in python-trunk and it still seems to need to be fixed. I'd recommend it gets checked in for the 2.6 release. I'd like one of the distutils people to confirm this though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-21 02:17 Message: Logged In: YES user_id=33168 Sean, you seem to know a lot more about rpms than most of us. Any comment on this approach? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360200&group_id=5470 From noreply at sourceforge.net Sun Sep 3 03:09:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 18:09:10 -0700 Subject: [Patches] [ python-Patches-1550886 ] Fix decimal context management for 2.5 Message-ID: Patches item #1550886, was opened at 2006-09-02 14:39 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550886&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: Accepted Priority: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix decimal context management for 2.5 Initial Comment: Backport of the decimal module context management fixes already implemented on the trunk after discussion with Raymond. Also includes an appropriate update to the Python 2.5 What's New. Without this patch, the code, docstrings, standard library reference and What's New all say different things about the updated decimal context management API. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-03 11:09 Message: Logged In: YES user_id=1038590 A variant of this has been committed as rev 51695 (rev 51694 was the last related update on the trunk). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550886&group_id=5470 From noreply at sourceforge.net Sun Sep 3 08:48:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 23:48:55 -0700 Subject: [Patches] [ python-Patches-1551339 ] Fix for rpartition() end-case Message-ID: Patches item #1551339, was opened at 2006-09-03 01:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for rpartition() end-case Initial Comment: Per discussion on python-dev ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&group_id=5470 From noreply at sourceforge.net Sun Sep 3 08:49:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Sep 2006 23:49:49 -0700 Subject: [Patches] [ python-Patches-1551340 ] Updated spec file for 2.5 release. Message-ID: Patches item #1551340, was opened at 2006-09-03 06: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=1551340&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: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Sean Reifschneider (jafo) Assigned to: Anthony Baxter (anthonybaxter) Summary: Updated spec file for 2.5 release. Initial Comment: This is an updated spec file which fixes some problems with changes made in 2.5. This version builds on my test machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551340&group_id=5470 From noreply at sourceforge.net Mon Sep 4 15:07:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 06:07:13 -0700 Subject: [Patches] [ python-Patches-1551339 ] Fix for rpartition() end-case Message-ID: Patches item #1551339, was opened at 2006-09-03 16:48 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for rpartition() end-case Initial Comment: Per discussion on python-dev ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-04 23:07 Message: Logged In: YES user_id=1038590 Aside from the tests, the patch looks OK. (A search through the standard library showed that the only current use of rpartition() is in UserString.py, which will correctly inherit the behaviour of the underlying string type). For the tests, the degenerate cases are already tested (second test in each group), so new test cases aren't necessary. Instead, the expected result for the degenerate rpartition test needs to be updated. (Also, the second test case added by the patch invoked partition() instead of rpartition()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&group_id=5470 From noreply at sourceforge.net Mon Sep 4 16:53:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 07:53:19 -0700 Subject: [Patches] [ python-Patches-1552024 ] unparse.py decorator support Message-ID: Patches item #1552024, was opened at 2006-09-04 17: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=1552024&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: Demos and tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: unparse.py decorator support Initial Comment: I've added decorator output support to /Demo/parser/unparse.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552024&group_id=5470 From noreply at sourceforge.net Mon Sep 4 19:05:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 10:05:06 -0700 Subject: [Patches] [ python-Patches-1552093 ] eval docstring typo Message-ID: Patches item #1552093, was opened at 2006-09-04 20:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552093&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: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: eval docstring typo Initial Comment: mappping -> mapping. Attaching patch against r51704 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552093&group_id=5470 From noreply at sourceforge.net Tue Sep 5 00:20:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 15:20:23 -0700 Subject: [Patches] [ python-Patches-1551339 ] Fix for rpartition() end-case Message-ID: Patches item #1551339, was opened at 2006-09-03 01:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for rpartition() end-case Initial Comment: Per discussion on python-dev ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-04 17:20 Message: Logged In: YES user_id=80475 Neal, please move this from the head to the release branch when you're ready. Nick, thanks for the review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-04 08:07 Message: Logged In: YES user_id=1038590 Aside from the tests, the patch looks OK. (A search through the standard library showed that the only current use of rpartition() is in UserString.py, which will correctly inherit the behaviour of the underlying string type). For the tests, the degenerate cases are already tested (second test in each group), so new test cases aren't necessary. Instead, the expected result for the degenerate rpartition test needs to be updated. (Also, the second test case added by the patch invoked partition() instead of rpartition()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&group_id=5470 From noreply at sourceforge.net Tue Sep 5 03:36:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 18:36:57 -0700 Subject: [Patches] [ python-Patches-1551340 ] Updated spec file for 2.5 release. Message-ID: Patches item #1551340, was opened at 2006-09-02 23:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551340&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: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Sean Reifschneider (jafo) Assigned to: Anthony Baxter (anthonybaxter) Summary: Updated spec file for 2.5 release. Initial Comment: This is an updated spec file which fixes some problems with changes made in 2.5. This version builds on my test machine. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 18:36 Message: Logged In: YES user_id=33168 I updated the release to c2. I noticed that there are these lines: grep -v -e '\\.pyc$' -e '\\.pyo$' | grep '\.py$' tools.files | sed 's/$/c/' | ... Shouldn't the second line also use a double backslash? Sean, you can make changes in SVN for the spec file. Committed revision 51710. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551340&group_id=5470 From noreply at sourceforge.net Tue Sep 5 03:52:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 18:52:23 -0700 Subject: [Patches] [ python-Patches-1552093 ] eval docstring typo Message-ID: Patches item #1552093, was opened at 2006-09-04 10:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552093&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: Fixed Priority: 5 Submitted By: Ori Avtalion (salty-horse) >Assigned to: Neal Norwitz (nnorwitz) Summary: eval docstring typo Initial Comment: mappping -> mapping. Attaching patch against r51704 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 18:52 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51712. (2.5) I'll check in to 2.6 in a bit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552093&group_id=5470 From noreply at sourceforge.net Tue Sep 5 03:54:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 18:54:31 -0700 Subject: [Patches] [ python-Patches-1546288 ] crash in dict_equal Message-ID: Patches item #1546288, was opened at 2006-08-24 15:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&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.6 Status: Open >Resolution: None >Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neal Norwitz (nnorwitz) Summary: crash in dict_equal Initial Comment: I initially found this bug in the py3k branch, but it's reproducible in 2.5 as well (and probably older versions as well, as long as they have dict_equal()). It can be reproduced by using the attached patch to test_mutants.py. The problem is in this fragment in dict_equal(): PyObject *key = a->ma_table[i].me_key; /* temporarily bump aval's refcount to ensure it stays alive until we're done with it */ Py_INCREF(aval); bval = PyDict_GetItem((PyObject *)b, key); The problem is that the only reference to 'key' may be in the hash table, and test_mutants.py removes it from the hash table, apparently before the comparison code is done with using it. The fix is to incref/decref key around the GetItem call. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 18:54 Message: Logged In: YES user_id=33168 Committed revision 51713. 2.5 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 17:23 Message: Logged In: YES user_id=33168 Defer until 2.5.1. I'll apply later. (If I forget, someone please checkin after 2.5 is out the door. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&group_id=5470 From noreply at sourceforge.net Tue Sep 5 04:21:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 19:21:54 -0700 Subject: [Patches] [ python-Patches-1551339 ] Fix for rpartition() end-case Message-ID: Patches item #1551339, was opened at 2006-09-02 23:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for rpartition() end-case Initial Comment: Per discussion on python-dev ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:21 Message: Logged In: YES user_id=33168 This patch is different than what's on HEAD (some files, in particular partition.h and string_tests.py). HEAD passes, this one doesn't. I'm using the version from head. Committed revision 51718. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-04 15:20 Message: Logged In: YES user_id=80475 Neal, please move this from the head to the release branch when you're ready. Nick, thanks for the review. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-04 06:07 Message: Logged In: YES user_id=1038590 Aside from the tests, the patch looks OK. (A search through the standard library showed that the only current use of rpartition() is in UserString.py, which will correctly inherit the behaviour of the underlying string type). For the tests, the degenerate cases are already tested (second test in each group), so new test cases aren't necessary. Instead, the expected result for the degenerate rpartition test needs to be updated. (Also, the second test case added by the patch invoked partition() instead of rpartition()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551339&group_id=5470 From noreply at sourceforge.net Tue Sep 5 04:24:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 19:24:33 -0700 Subject: [Patches] [ python-Patches-1546288 ] crash in dict_equal Message-ID: Patches item #1546288, was opened at 2006-08-24 15:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neal Norwitz (nnorwitz) Summary: crash in dict_equal Initial Comment: I initially found this bug in the py3k branch, but it's reproducible in 2.5 as well (and probably older versions as well, as long as they have dict_equal()). It can be reproduced by using the attached patch to test_mutants.py. The problem is in this fragment in dict_equal(): PyObject *key = a->ma_table[i].me_key; /* temporarily bump aval's refcount to ensure it stays alive until we're done with it */ Py_INCREF(aval); bval = PyDict_GetItem((PyObject *)b, key); The problem is that the only reference to 'key' may be in the hash table, and test_mutants.py removes it from the hash table, apparently before the comparison code is done with using it. The fix is to incref/decref key around the GetItem call. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:24 Message: Logged In: YES user_id=33168 Committed revision 51720. (2.6) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 18:54 Message: Logged In: YES user_id=33168 Committed revision 51713. 2.5 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 17:23 Message: Logged In: YES user_id=33168 Defer until 2.5.1. I'll apply later. (If I forget, someone please checkin after 2.5 is out the door. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&group_id=5470 From noreply at sourceforge.net Tue Sep 5 04:46:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 19:46:08 -0700 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-18 18:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&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: Out of Date Priority: 6 Submitted By: baus (cbaus) Assigned to: Anthony Baxter (anthonybaxter) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:46 Message: Logged In: YES user_id=33168 This patch doesn't apply to 2.5. 2.6 is probably the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Tue Sep 5 04:57:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Sep 2006 19:57:17 -0700 Subject: [Patches] [ python-Patches-1540470 ] Patches for OpenBSD 4.0 Message-ID: Patches item #1540470, was opened at 2006-08-15 01:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&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: Python 2.5 >Status: Closed >Resolution: Accepted >Priority: 5 Submitted By: Damien Miller (djmdjm) Assigned to: Neal Norwitz (nnorwitz) Summary: Patches for OpenBSD 4.0 Initial Comment: Hi, There are several points in the Python-2.5b3 code that need to be modified to properly support OpenBSD 4.x. This is mostly because of a dependence on sys.platform returning "openbsd3", which is no longer true for OpenBSD CVS - OpenBSD 4.0 is in beta right now, to be released in a couple of months. The attached patch (against SVN head) fixes this. It would be great if this can make it in for Python-2.5. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:57 Message: Logged In: YES user_id=33168 I modified the change to configure.in to be explicit. This is generally what we do so if the platform does change, we are ok. Committed revision 51727. 2.5 Committed revision 51728. ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-18 22:25 Message: Logged In: YES user_id=1359232 No, these patches are required to build and pass regress on OpenBSD 4.0. It wasn't a simple search and replace exercise. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 20:23 Message: Logged In: YES user_id=33168 Did you confirm that each of these hunks are necessary with 4.0 or did you just copy anywhere there was openbsd3 and add openbsd4? Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 04:13 Message: Logged In: YES user_id=849994 Speaking of OpenBSD, Gentoo has an additional patch to compile for OpenBSD, I'll attach it here without looking into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 From noreply at sourceforge.net Tue Sep 5 15:41:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 06:41:05 -0700 Subject: [Patches] [ python-Patches-1551340 ] Updated spec file for 2.5 release. Message-ID: Patches item #1551340, was opened at 2006-09-03 06:49 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551340&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: Python 2.5 Status: Closed Resolution: Accepted Priority: 6 Submitted By: Sean Reifschneider (jafo) Assigned to: Anthony Baxter (anthonybaxter) Summary: Updated spec file for 2.5 release. Initial Comment: This is an updated spec file which fixes some problems with changes made in 2.5. This version builds on my test machine. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2006-09-05 13:41 Message: Logged In: YES user_id=81797 Good spot, thanks. Actually, the first line should be single backslashes. I was just lucky because the file doesn't currently contain pyc/pyo files. I had added the double backslashes in a moment of confusion. Fixed, tested, and committed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 01:36 Message: Logged In: YES user_id=33168 I updated the release to c2. I noticed that there are these lines: grep -v -e '\\.pyc$' -e '\\.pyo$' | grep '\.py$' tools.files | sed 's/$/c/' | ... Shouldn't the second line also use a double backslash? Sean, you can make changes in SVN for the spec file. Committed revision 51710. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1551340&group_id=5470 From noreply at sourceforge.net Tue Sep 5 16:47:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 07:47:49 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 09: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=1552731&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Tue Sep 5 20:11:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 11:11:31 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-05 18: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=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Tue Sep 5 22:07:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 13:07:50 -0700 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-18 18:44 Message generated for change (Comment added) made by cbaus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&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: Out of Date Priority: 6 Submitted By: baus (cbaus) Assigned to: Anthony Baxter (anthonybaxter) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- >Comment By: baus (cbaus) Date: 2006-09-05 13:07 Message: Logged In: YES user_id=1579156 The patch doesn't apply cleanly, or adding this module to the project doesn't apply? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:46 Message: Logged In: YES user_id=33168 This patch doesn't apply to 2.5. 2.6 is probably the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Tue Sep 5 22:14:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 13:14:56 -0700 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-18 18:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&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: Out of Date Priority: 6 Submitted By: baus (cbaus) Assigned to: Anthony Baxter (anthonybaxter) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 13:14 Message: Logged In: YES user_id=33168 The patch doesn't apply. I don't have a windows box, so I can't even test it. All I can do is apply. ---------------------------------------------------------------------- Comment By: baus (cbaus) Date: 2006-09-05 13:07 Message: Logged In: YES user_id=1579156 The patch doesn't apply cleanly, or adding this module to the project doesn't apply? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-04 19:46 Message: Logged In: YES user_id=33168 This patch doesn't apply to 2.5. 2.6 is probably the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:42:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:42:48 -0700 Subject: [Patches] [ python-Patches-1550800 ] make exec a function Message-ID: Patches item #1550800, was opened at 2006-09-01 18:35 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550800&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: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: make exec a function Initial Comment: Make exec a function, as described in PEP 3100. exec() now cannot modify the locals. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 02:42 Message: Logged In: YES user_id=6380 Cool. Very thorough! Please check it in yourself (makes more sense for auditing etc.) and close. (I've already marked it as "done" in the PEP.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550800&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:46:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:46:23 -0700 Subject: [Patches] [ python-Patches-1550786 ] Ellipsis literal "..." Message-ID: Patches item #1550786, was opened at 2006-09-01 18:15 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550786&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: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: Ellipsis literal "..." Initial Comment: This patch makes ... a generally usable expression, as described in PEP 3100. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 02:46 Message: Logged In: YES user_id=6380 Also cool. Please check this in yourself, and close. (Later, I think '...' ought to be a single token recognized by the lexer; that prevents abominations like ". . ." -- but please check the current patch in first.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550786&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:48:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:48:21 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 04:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 02:48 Message: Logged In: YES user_id=6380 Do you think this is ready to be checked in, or are you still working on it? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-01 05:38 Message: Logged In: YES user_id=849994 Since you can put anything usable as an assignment target after the "for" of a listcomp, just renaming might be complicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 19:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 19:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 15:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 18:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 15:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 13:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 04:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:53:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:53:24 -0700 Subject: [Patches] [ python-Patches-1550800 ] make exec a function Message-ID: Patches item #1550800, was opened at 2006-09-01 22:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550800&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: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: make exec a function Initial Comment: Make exec a function, as described in PEP 3100. exec() now cannot modify the locals. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:53 Message: Logged In: YES user_id=849994 Committed as rev. 51771. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 06:42 Message: Logged In: YES user_id=6380 Cool. Very thorough! Please check it in yourself (makes more sense for auditing etc.) and close. (I've already marked it as "done" in the PEP.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550800&group_id=5470 From noreply at sourceforge.net Wed Sep 6 08:54:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Sep 2006 23:54:16 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 14:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Wed Sep 6 09:03:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 00:03:16 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 07:03 Message: Logged In: YES user_id=849994 It is complete, it works and it does not leak the loop variable(s). The question is whether it is okay for listcomps and setcomps to be in their own anonymous function, which slows listcomps down compared to the 2.x branch. I don't know why the function approach was taken for genexps, but I suspect it was because who implemented it then saw this as the best way to hide the loop variable. Perhaps somebody else more familiar with the internals and the previous discussions can look over it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 06:48 Message: Logged In: YES user_id=6380 Do you think this is ready to be checked in, or are you still working on it? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-01 09:38 Message: Logged In: YES user_id=849994 Since you can put anything usable as an assignment target after the "for" of a listcomp, just renaming might be complicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 23:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 19:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 22:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 19:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 17:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 08:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Wed Sep 6 09:04:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 00:04:53 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 07:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: Accepted Priority: 7 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 00:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 23:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Wed Sep 6 09:08:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 00:08:30 -0700 Subject: [Patches] [ python-Patches-1550786 ] Ellipsis literal "..." Message-ID: Patches item #1550786, was opened at 2006-09-01 22:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550786&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: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: Ellipsis literal "..." Initial Comment: This patch makes ... a generally usable expression, as described in PEP 3100. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 07:08 Message: Logged In: YES user_id=849994 Checked in as rev. 51773. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 06:46 Message: Logged In: YES user_id=6380 Also cool. Please check this in yourself, and close. (Later, I think '...' ought to be a single token recognized by the lexer; that prevents abominations like ". . ." -- but please check the current patch in first.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550786&group_id=5470 From noreply at sourceforge.net Wed Sep 6 09:09:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 00:09:12 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 14:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: Accepted Priority: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 07:09 Message: Logged In: YES user_id=849994 That misses the possibility of set_contains_key's return value being 0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 07:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Wed Sep 6 12:51:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 03:51:39 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 20: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=1553314&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Wed Sep 6 14:48:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 05:48:51 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 20:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 22:48 Message: Logged In: YES user_id=1038590 Low impact approach that simply checks the linecache directly before doing anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Wed Sep 6 15:04:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 06:04:13 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 20:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 23:04 Message: Logged In: YES user_id=1038590 Bah. The linecache version has the same problem as the previous version - it's the failure case that searches the whole of sys.modules that is slow, not the success case. Patch attached which stores a mapping from module names to module.__file__ values and skips the absolute lookup if the value of module.__file__ hasn't changed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 22:48 Message: Logged In: YES user_id=1038590 Low impact approach that simply checks the linecache directly before doing anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Wed Sep 6 15:49:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 06:49:17 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 10:51 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-09-06 13:49 Message: Logged In: YES user_id=56214 I just looked at the current patch; please don't use sys.modules.iteritems() in your search loop; it'll break if touching a module causes another module to be imported. This can happen if somebody is using one of the many "lazy import" tools out there. Use .items() instead. Second, there was a reason that the loop used module.__name__ instead of the sys.modules keys; a module can be listed under more than one sys.modules key, so the loop was storing the *canonical* name of the module. I'm not 100% positive this is a critical thing, but I'm suspicious of the idea of just randomly choosing which of the possible keys should be used. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 13:04 Message: Logged In: YES user_id=1038590 Bah. The linecache version has the same problem as the previous version - it's the failure case that searches the whole of sys.modules that is slow, not the success case. Patch attached which stores a mapping from module names to module.__file__ values and skips the absolute lookup if the value of module.__file__ hasn't changed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=1038590 Low impact approach that simply checks the linecache directly before doing anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Wed Sep 6 16:00:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 07:00:57 -0700 Subject: [Patches] [ python-Patches-1553427 ] locale.getdefaultlocale() bug when _locale is missing Message-ID: Patches item #1553427, was opened at 2006-09-06 16:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553427&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: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultlocale() bug when _locale is missing Initial Comment: locale.getdefaultlocale() is not able to get my terminal charset when _locale is missing. My variable environement (I'm using Kubuntu Dapper): $ env|egrep '(LANG|LC_)' LANG=fr_FR.UTF-8 LANGUAGE=fr_FR:fr:en_GB:en The problem is that locale.getdefaultlocale() try to use $LANGUAGE before $LANG, and $LANGUAGE don't contain charset information. So I choosed to test LANGUAGE as last change, and backport Python 2.5c1 patch (just use first language from $LANGUAGE: localename = localename.split(':') [0]). The bug should be in Python 2.x (at least 2.4.x and 2.5.x). Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553427&group_id=5470 From noreply at sourceforge.net Wed Sep 6 17:36:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 08:36:18 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 04:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 11:36 Message: Logged In: YES user_id=6380 I always assumed that the genexps *require* being a function because that's the only way to create a generator. But that argument doesn't apply to listcomps. That's about all I know of the implementation of these.. :-( Have you asked python-dev? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 03:03 Message: Logged In: YES user_id=849994 It is complete, it works and it does not leak the loop variable(s). The question is whether it is okay for listcomps and setcomps to be in their own anonymous function, which slows listcomps down compared to the 2.x branch. I don't know why the function approach was taken for genexps, but I suspect it was because who implemented it then saw this as the best way to hide the loop variable. Perhaps somebody else more familiar with the internals and the previous discussions can look over it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 02:48 Message: Logged In: YES user_id=6380 Do you think this is ready to be checked in, or are you still working on it? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-01 05:38 Message: Logged In: YES user_id=849994 Since you can put anything usable as an assignment target after the "for" of a listcomp, just renaming might be complicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 19:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 19:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 15:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 18:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 15:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 13:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 04:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Thu Sep 7 08:58:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Sep 2006 23:58:35 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 03:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 23:58 Message: Logged In: YES user_id=33168 I had the same question as pje wrt to his second comment about module.__name__ (assuming this is the same patch posted to python-dev). I would rather use the version currently checked in to minimize change and maximize the testing. Please add a comments describing why one is chosen rather than the other. Also adding a comment in the code about pje's items comment below would be nice. Is this the attached version the same one Ralf (or whoever) said fixed the problem? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2006-09-06 06:49 Message: Logged In: YES user_id=56214 I just looked at the current patch; please don't use sys.modules.iteritems() in your search loop; it'll break if touching a module causes another module to be imported. This can happen if somebody is using one of the many "lazy import" tools out there. Use .items() instead. Second, there was a reason that the loop used module.__name__ instead of the sys.modules keys; a module can be listed under more than one sys.modules key, so the loop was storing the *canonical* name of the module. I'm not 100% positive this is a critical thing, but I'm suspicious of the idea of just randomly choosing which of the possible keys should be used. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 06:04 Message: Logged In: YES user_id=1038590 Bah. The linecache version has the same problem as the previous version - it's the failure case that searches the whole of sys.modules that is slow, not the success case. Patch attached which stores a mapping from module names to module.__file__ values and skips the absolute lookup if the value of module.__file__ hasn't changed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 05:48 Message: Logged In: YES user_id=1038590 Low impact approach that simply checks the linecache directly before doing anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Thu Sep 7 09:05:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 00:05:54 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 07:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: Accepted Priority: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 00:05 Message: Logged In: YES user_id=33168 rev 51798 for 2.6 was checked in. Georg, true. I was thinking that something like this would be nicer: int rv = set_contains_key(so, key); if (rv == -1 || (rv != 0 && set_add_key(result, key) == -1)) { I figured the transformation would be easy. But now that I look at the code above, I really don't like that at all. The only other solution I can think of is to use a goto: int rv = set_contains_key(so, key); if (rv == -1) goto some_error; if (rv) { if (set_add_key(result, key) == -1) { some_error: I'm not really sure I like that either. So basically no matter which way the code looks, I'm not gonna be happy. :-) Oh well. Raymond, were you planning on backporting this or did you want someone else to? I volunteer to backport to 2.4. ;-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 00:09 Message: Logged In: YES user_id=849994 That misses the possibility of set_contains_key's return value being 0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 00:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-05 23:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Thu Sep 7 12:53:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 03:53:54 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 20:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-07 20:53 Message: Logged In: YES user_id=1038590 I beefed up the tests to pick up the error Ralf spotted in the previous version of the patch, and added more comments to getmodule() to explain why some things are the way they are (specifically the use of sys.modules.items() and the use of module.__name__). Committed to the trunk - I'll backport tomorrow night unless Neal objects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 16:58 Message: Logged In: YES user_id=33168 I had the same question as pje wrt to his second comment about module.__name__ (assuming this is the same patch posted to python-dev). I would rather use the version currently checked in to minimize change and maximize the testing. Please add a comments describing why one is chosen rather than the other. Also adding a comment in the code about pje's items comment below would be nice. Is this the attached version the same one Ralf (or whoever) said fixed the problem? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2006-09-06 23:49 Message: Logged In: YES user_id=56214 I just looked at the current patch; please don't use sys.modules.iteritems() in your search loop; it'll break if touching a module causes another module to be imported. This can happen if somebody is using one of the many "lazy import" tools out there. Use .items() instead. Second, there was a reason that the loop used module.__name__ instead of the sys.modules keys; a module can be listed under more than one sys.modules key, so the loop was storing the *canonical* name of the module. I'm not 100% positive this is a critical thing, but I'm suspicious of the idea of just randomly choosing which of the possible keys should be used. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 23:04 Message: Logged In: YES user_id=1038590 Bah. The linecache version has the same problem as the previous version - it's the failure case that searches the whole of sys.modules that is slow, not the success case. Patch attached which stores a mapping from module names to module.__file__ values and skips the absolute lookup if the value of module.__file__ hasn't changed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 22:48 Message: Logged In: YES user_id=1038590 Low impact approach that simply checks the linecache directly before doing anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Thu Sep 7 19:58:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 10:58:19 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&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: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-09-08 02:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 14:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Thu Sep 7 22:13:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 13:13:24 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 09:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: Accepted Priority: 7 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Georg Brandl (gbrandl) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-07 15:13 Message: Logged In: YES user_id=80475 Georg, the buildbot seems to be happy with this patch as applied to the head, would you please backport it to the Py2.5 release for me (since I'm away from my svn commit machine for a while). Thanks, Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 02:05 Message: Logged In: YES user_id=33168 rev 51798 for 2.6 was checked in. Georg, true. I was thinking that something like this would be nicer: int rv = set_contains_key(so, key); if (rv == -1 || (rv != 0 && set_add_key(result, key) == -1)) { I figured the transformation would be easy. But now that I look at the code above, I really don't like that at all. The only other solution I can think of is to use a goto: int rv = set_contains_key(so, key); if (rv == -1) goto some_error; if (rv) { if (set_add_key(result, key) == -1) { some_error: I'm not really sure I like that either. So basically no matter which way the code looks, I'm not gonna be happy. :-) Oh well. Raymond, were you planning on backporting this or did you want someone else to? I volunteer to backport to 2.4. ;-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 02:09 Message: Logged In: YES user_id=849994 That misses the possibility of set_contains_key's return value being 0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 01:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Fri Sep 8 08:03:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 23:03:45 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 14:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: 7 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Neal Norwitz (nnorwitz) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-08 06:03 Message: Logged In: YES user_id=849994 Sure. Committed revision 51825 for 2.5 branch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-07 20:13 Message: Logged In: YES user_id=80475 Georg, the buildbot seems to be happy with this patch as applied to the head, would you please backport it to the Py2.5 release for me (since I'm away from my svn commit machine for a while). Thanks, Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 07:05 Message: Logged In: YES user_id=33168 rev 51798 for 2.6 was checked in. Georg, true. I was thinking that something like this would be nicer: int rv = set_contains_key(so, key); if (rv == -1 || (rv != 0 && set_add_key(result, key) == -1)) { I figured the transformation would be easy. But now that I look at the code above, I really don't like that at all. The only other solution I can think of is to use a goto: int rv = set_contains_key(so, key); if (rv == -1) goto some_error; if (rv) { if (set_add_key(result, key) == -1) { some_error: I'm not really sure I like that either. So basically no matter which way the code looks, I'm not gonna be happy. :-) Oh well. Raymond, were you planning on backporting this or did you want someone else to? I volunteer to backport to 2.4. ;-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 07:09 Message: Logged In: YES user_id=849994 That misses the possibility of set_contains_key's return value being 0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 07:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Fri Sep 8 08:03:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Sep 2006 23:03:55 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 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=1552731&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: Accepted Priority: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-08 06:03 Message: Logged In: YES user_id=849994 Sure. Committed revision 51825 for 2.5 branch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-07 20:13 Message: Logged In: YES user_id=80475 Georg, the buildbot seems to be happy with this patch as applied to the head, would you please backport it to the Py2.5 release for me (since I'm away from my svn commit machine for a while). Thanks, Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 07:05 Message: Logged In: YES user_id=33168 rev 51798 for 2.6 was checked in. Georg, true. I was thinking that something like this would be nicer: int rv = set_contains_key(so, key); if (rv == -1 || (rv != 0 && set_add_key(result, key) == -1)) { I figured the transformation would be easy. But now that I look at the code above, I really don't like that at all. The only other solution I can think of is to use a goto: int rv = set_contains_key(so, key); if (rv == -1) goto some_error; if (rv) { if (set_add_key(result, key) == -1) { some_error: I'm not really sure I like that either. So basically no matter which way the code looks, I'm not gonna be happy. :-) Oh well. Raymond, were you planning on backporting this or did you want someone else to? I volunteer to backport to 2.4. ;-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 07:09 Message: Logged In: YES user_id=849994 That misses the possibility of set_contains_key's return value being 0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 07:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 06:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Fri Sep 8 12:02:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 03:02:43 -0700 Subject: [Patches] [ python-Patches-1553314 ] Fix inspect.py 2.5 slowdown Message-ID: Patches item #1553314, was opened at 2006-09-06 20:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&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: Accepted Priority: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix inspect.py 2.5 slowdown Initial Comment: Every call to inspect.findsource() in Python 2.5 is calling both os.path.abspath() and os.path.normpath(), even if the file name is already absolute and normalized, and the relevant entry is in the module name cache. This patch changes getmodule() to first check the modulesbyfile cache earlier, so these calls are skipped when the module name for the file is already known. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-08 20:02 Message: Logged In: YES user_id=1038590 Applied as rev 51803 on head. Backported to 2.5 as rev 51826. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-07 20:53 Message: Logged In: YES user_id=1038590 I beefed up the tests to pick up the error Ralf spotted in the previous version of the patch, and added more comments to getmodule() to explain why some things are the way they are (specifically the use of sys.modules.items() and the use of module.__name__). Committed to the trunk - I'll backport tomorrow night unless Neal objects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 16:58 Message: Logged In: YES user_id=33168 I had the same question as pje wrt to his second comment about module.__name__ (assuming this is the same patch posted to python-dev). I would rather use the version currently checked in to minimize change and maximize the testing. Please add a comments describing why one is chosen rather than the other. Also adding a comment in the code about pje's items comment below would be nice. Is this the attached version the same one Ralf (or whoever) said fixed the problem? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2006-09-06 23:49 Message: Logged In: YES user_id=56214 I just looked at the current patch; please don't use sys.modules.iteritems() in your search loop; it'll break if touching a module causes another module to be imported. This can happen if somebody is using one of the many "lazy import" tools out there. Use .items() instead. Second, there was a reason that the loop used module.__name__ instead of the sys.modules keys; a module can be listed under more than one sys.modules key, so the loop was storing the *canonical* name of the module. I'm not 100% positive this is a critical thing, but I'm suspicious of the idea of just randomly choosing which of the possible keys should be used. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 23:04 Message: Logged In: YES user_id=1038590 Bah. The linecache version has the same problem as the previous version - it's the failure case that searches the whole of sys.modules that is slow, not the success case. Patch attached which stores a mapping from module names to module.__file__ values and skips the absolute lookup if the value of module.__file__ hasn't changed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-09-06 22:48 Message: Logged In: YES user_id=1038590 Low impact approach that simply checks the linecache directly before doing anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553314&group_id=5470 From noreply at sourceforge.net Fri Sep 8 18:02:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 09:02:28 -0700 Subject: [Patches] [ python-Patches-1552731 ] Fix error checks and leaks in setobject.c Message-ID: Patches item #1552731, was opened at 2006-09-05 09:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&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: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix error checks and leaks in setobject.c Initial Comment: Check return values for errors. Fix refcounts on the error returns; ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-08 01:03 Message: Logged In: YES user_id=849994 Sure. Committed revision 51825 for 2.5 branch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-07 15:13 Message: Logged In: YES user_id=80475 Georg, the buildbot seems to be happy with this patch as applied to the head, would you please backport it to the Py2.5 release for me (since I'm away from my svn commit machine for a while). Thanks, Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 02:05 Message: Logged In: YES user_id=33168 rev 51798 for 2.6 was checked in. Georg, true. I was thinking that something like this would be nicer: int rv = set_contains_key(so, key); if (rv == -1 || (rv != 0 && set_add_key(result, key) == -1)) { I figured the transformation would be easy. But now that I look at the code above, I really don't like that at all. The only other solution I can think of is to use a goto: int rv = set_contains_key(so, key); if (rv == -1) goto some_error; if (rv) { if (set_add_key(result, key) == -1) { some_error: I'm not really sure I like that either. So basically no matter which way the code looks, I'm not gonna be happy. :-) Oh well. Raymond, were you planning on backporting this or did you want someone else to? I volunteer to backport to 2.4. ;-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 02:09 Message: Logged In: YES user_id=849994 That misses the possibility of set_contains_key's return value being 0. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:04 Message: Logged In: YES user_id=33168 This is fine. Though I wonder if hunks like this: - if (set_contains_key(so, key)) { + int rv = set_contains_key(so, key); + if (rv == -1) { + Py_DECREF(it); + Py_DECREF(result); + Py_DECREF(key); + return NULL; + } + if (rv) { if (set_add_key(result, key) == -1) { would be clearer (to me at least) more like: if (set_contains_key(so, key) == -1 || set_add_key(result, key) == -1) { That ensures the cleanup is the same. There are several similar hunks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 01:54 Message: Logged In: YES user_id=849994 Shouldn't this go into 2.5 final? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552731&group_id=5470 From noreply at sourceforge.net Fri Sep 8 19:13:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 10:13:59 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 03:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&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: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-08 12:13 Message: Logged In: YES user_id=80475 Genexps necessarily need a separate stack frame to achieve saved execution state (including the instruction pointer and local variable). Also, it was simplest to implement genexps in terms of the existing and proven code for regular generators. For list and set comps, I think you can take a simpler approach and just rename the inner loop variable to something invisible. That will make it faster, make the disassemby readable, and make it easier to follow in pdb. Also, we get to capitalize on proven code -- they only difference is that the induction variable won't be visible to surrounding code. Since what you have works, I would say just check it in; however, it would probably never get touched again and an early, arbitrary design choice would get set in stone. My bet is that the renaming approach will result in a much simpler patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 10:36 Message: Logged In: YES user_id=6380 I always assumed that the genexps *require* being a function because that's the only way to create a generator. But that argument doesn't apply to listcomps. That's about all I know of the implementation of these.. :-( Have you asked python-dev? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 02:03 Message: Logged In: YES user_id=849994 It is complete, it works and it does not leak the loop variable(s). The question is whether it is okay for listcomps and setcomps to be in their own anonymous function, which slows listcomps down compared to the 2.x branch. I don't know why the function approach was taken for genexps, but I suspect it was because who implemented it then saw this as the best way to hide the loop variable. Perhaps somebody else more familiar with the internals and the previous discussions can look over it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 01:48 Message: Logged In: YES user_id=6380 Do you think this is ready to be checked in, or are you still working on it? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-01 04:38 Message: Logged In: YES user_id=849994 Since you can put anything usable as an assignment target after the "for" of a listcomp, just renaming might be complicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 18:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 18:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 14:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 17:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 14:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 12:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 03:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Fri Sep 8 23:03:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 14:03:12 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-05 20:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-09-08 23:03 Message: Logged In: YES user_id=21627 What is the value of the __file__ attribute of a module when this patch is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Sat Sep 9 02:45:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 17:45:40 -0700 Subject: [Patches] [ python-Patches-1555097 ] UserDict New Style Message-ID: Patches item #1555097, was opened at 2006-09-09 03: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=1555097&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: Indy (indy90) Assigned to: Nobody/Anonymous (nobody) Summary: UserDict New Style Initial Comment: Made classes in UserDict inherit from object, and made the decorator classmethod, in new style way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555097&group_id=5470 From noreply at sourceforge.net Sat Sep 9 02:46:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 17:46:52 -0700 Subject: [Patches] [ python-Patches-1555098 ] Performance enhancements. Message-ID: Patches item #1555098, was opened at 2006-09-09 03: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=1555098&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: Indy (indy90) Assigned to: Nobody/Anonymous (nobody) Summary: Performance enhancements. Initial Comment: Implemeted some performance enhancements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&group_id=5470 From noreply at sourceforge.net Sat Sep 9 04:02:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 19:02:47 -0700 Subject: [Patches] [ python-Patches-1555097 ] UserDict New Style Message-ID: Patches item #1555097, was opened at 2006-09-08 19:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555097&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Indy (indy90) Assigned to: Nobody/Anonymous (nobody) Summary: UserDict New Style Initial Comment: Made classes in UserDict inherit from object, and made the decorator classmethod, in new style way. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-08 21:02 Message: Logged In: YES user_id=80475 Sorry, changing from old style to new-style is not a backwards compatible change. If we were going to do this, it would have happened long ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555097&group_id=5470 From noreply at sourceforge.net Sat Sep 9 04:08:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 19:08:39 -0700 Subject: [Patches] [ python-Patches-1555098 ] Performance enhancements. Message-ID: Patches item #1555098, was opened at 2006-09-08 19:46 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&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: Indy (indy90) >Assigned to: Raymond Hettinger (rhettinger) Summary: Performance enhancements. Initial Comment: Implemeted some performance enhancements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&group_id=5470 From noreply at sourceforge.net Sat Sep 9 04:11:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Sep 2006 19:11:19 -0700 Subject: [Patches] [ python-Patches-1555098 ] Performance enhancements. Message-ID: Patches item #1555098, was opened at 2006-09-08 17:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&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: Indy (indy90) Assigned to: Raymond Hettinger (rhettinger) Summary: Performance enhancements. Initial Comment: Implemeted some performance enhancements. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-08 19:11 Message: Logged In: YES user_id=33168 Please create a context or unified diff against svn HEAD. Although I doubt robotparser changed between now and then, it is not easy to apply if there are other changes. Thanks. Also it would be good to describe what the performance enhancements actually are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&group_id=5470 From noreply at sourceforge.net Sat Sep 9 13:38:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 04:38:19 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-05 18:11 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2006-09-09 11:38 Message: Logged In: YES user_id=1262199 >From the top of my head, it is now unicode. I consider trying to convert it back to the default encoding but decided not to to keep the patch brief. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-08 21:03 Message: Logged In: YES user_id=21627 What is the value of the __file__ attribute of a module when this patch is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Sat Sep 9 14:31:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 05:31:47 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-05 20:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-09-09 14:31 Message: Logged In: YES user_id=21627 First: Do you want to continue to work on this, or do you consider this just "demonstration code" (i.e. not contributed for inclusion in Python), hoping that somebody else implements this feature? I think the behavior of __file__ must be more consistent across platforms, and the selected behaviour must be documented somewhere. Several definitions of "consistent behavior" come to mind: 1. __file__ is always a Unicode string 2. __file__ is a byte string if its ASCII, else Unicode 3. __file__ is a byte string if its in the system encoding, else Unicode 4. __file__ is a byte string if its in the file system encoding, else Unicode. The documentation needs to be updated in several places, e.g. also for inspect.getfile. I would expect that pydoc would also need to be updated. Selecting from the options above: I believe 4 is most compatible with previous versions; 1 and 2 are most convenient to work with in applications like pydoc which have to generate HTML (1 is easier to work with, 2 is more compatible with previous versions). ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2006-09-09 13:38 Message: Logged In: YES user_id=1262199 >From the top of my head, it is now unicode. I consider trying to convert it back to the default encoding but decided not to to keep the patch brief. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-08 23:03 Message: Logged In: YES user_id=21627 What is the value of the __file__ attribute of a module when this patch is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Sat Sep 9 17:48:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 08:48:35 -0700 Subject: [Patches] [ python-Patches-1555098 ] Performance enhancements. Message-ID: Patches item #1555098, was opened at 2006-09-08 19:46 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&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: Indy (indy90) Assigned to: Raymond Hettinger (rhettinger) Summary: Performance enhancements. Initial Comment: Implemeted some performance enhancements. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-09 10:48 Message: Logged In: YES user_id=80475 Attached is a cleaned-up version of the patch that focuses on using str.join instead of successive string addition. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-08 21:11 Message: Logged In: YES user_id=33168 Please create a context or unified diff against svn HEAD. Although I doubt robotparser changed between now and then, it is not easy to apply if there are other changes. Thanks. Also it would be good to describe what the performance enhancements actually are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&group_id=5470 From noreply at sourceforge.net Sun Sep 10 01:41:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 16:41:43 -0700 Subject: [Patches] [ python-Patches-1555570 ] email parser incorrectly breaks headers with a CRLF at 8192 Message-ID: Patches item #1555570, was opened at 2006-09-10 11:41 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=1555570&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: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: email parser incorrectly breaks headers with a CRLF at 8192 Initial Comment: If a message has a CRLF as part of a header that starts at 8191, the parser will incorrectly consider the headers to finish at 8191 and the body to start at 8193, which leaves headers in the body of the message. This problem occurs because the parser reads 8192 characters at a time. If 8192 is a '\r' and 8193 a '\n', then when the second block is parsed, it will appear to be a blank line (i.e. header separator). The simplest fix for this is to just read an extra character if the last one read is a '\r'. This appears to work fine without breaking anything, although I suppose that an alternative would be to change the FeedParser to check whether the '\n' belonged with the previous data. A patch and test are attached, against SVN of 10/Sept/06. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555570&group_id=5470 From noreply at sourceforge.net Sun Sep 10 01:42:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Sep 2006 16:42:22 -0700 Subject: [Patches] [ python-Patches-1555570 ] email parser incorrectly breaks headers with a CRLF at 8192 Message-ID: Patches item #1555570, was opened at 2006-09-10 11:41 Message generated for change (Settings changed) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555570&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: Tony Meyer (anadelonbrin) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email parser incorrectly breaks headers with a CRLF at 8192 Initial Comment: If a message has a CRLF as part of a header that starts at 8191, the parser will incorrectly consider the headers to finish at 8191 and the body to start at 8193, which leaves headers in the body of the message. This problem occurs because the parser reads 8192 characters at a time. If 8192 is a '\r' and 8193 a '\n', then when the second block is parsed, it will appear to be a blank line (i.e. header separator). The simplest fix for this is to just read an extra character if the last one read is a '\r'. This appears to work fine without breaking anything, although I suppose that an alternative would be to change the FeedParser to check whether the '\n' belonged with the previous data. A patch and test are attached, against SVN of 10/Sept/06. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555570&group_id=5470 From noreply at sourceforge.net Mon Sep 11 19:44:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 10:44:50 -0700 Subject: [Patches] [ python-Patches-858809 ] Use directories from configure rather than hardcoded Message-ID: Patches item #858809, was opened at 2003-12-12 11:24 Message generated for change (Comment added) made by spektrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&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: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal ?iha? (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Use directories from configure rather than hardcoded Initial Comment: Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64. Attached patch changes these paths to @libdir@ (and does also simmilar changes for other paths), which is usually outputed from configure. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:44 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&group_id=5470 From noreply at sourceforge.net Mon Sep 11 19:45:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 10:45:04 -0700 Subject: [Patches] [ python-Patches-858809 ] Use directories from configure rather than hardcoded Message-ID: Patches item #858809, was opened at 2003-12-12 11:24 Message generated for change (Comment added) made by spektrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&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: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal ?iha? (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Use directories from configure rather than hardcoded Initial Comment: Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64. Attached patch changes these paths to @libdir@ (and does also simmilar changes for other paths), which is usually outputed from configure. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:45 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:44 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&group_id=5470 From noreply at sourceforge.net Mon Sep 11 20:07:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 11:07:59 -0700 Subject: [Patches] [ python-Patches-858809 ] Use directories from configure rather than hardcoded Message-ID: Patches item #858809, was opened at 2003-12-12 11:24 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&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: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal ?iha? (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Use directories from configure rather than hardcoded Initial Comment: Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64. Attached patch changes these paths to @libdir@ (and does also simmilar changes for other paths), which is usually outputed from configure. ---------------------------------------------------------------------- >Comment By: Michal ?iha? (nijel) Date: 2006-09-11 20:07 Message: Logged In: YES user_id=192186 That doesn't surprise me, it was written in times of python 2.3... ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:45 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:44 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&group_id=5470 From noreply at sourceforge.net Mon Sep 11 21:51:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 12:51:56 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-30 21:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&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: Jiwon Seo (jiwon) >Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-11 15:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-07 13:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 01:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Mon Sep 11 22:12:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Sep 2006 13:12:40 -0700 Subject: [Patches] [ python-Patches-858809 ] Use directories from configure rather than hardcoded Message-ID: Patches item #858809, was opened at 2003-12-12 11:24 Message generated for change (Comment added) made by spektrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&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: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal ?iha? (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Use directories from configure rather than hardcoded Initial Comment: Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64. Attached patch changes these paths to @libdir@ (and does also simmilar changes for other paths), which is usually outputed from configure. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 22:12 Message: Logged In: YES user_id=631694 well obviously, but if you look at the patch, there is exactly -nothing- wrong with it. actually, i'm surprised that it didn't get into 2.4 release. but what's more, it should have no effect on setup.py at all ---------------------------------------------------------------------- Comment By: Michal ?iha? (nijel) Date: 2006-09-11 20:07 Message: Logged In: YES user_id=192186 That doesn't surprise me, it was written in times of python 2.3... ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:45 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2006-09-11 19:44 Message: Logged In: YES user_id=631694 this patch confuses the python 2.5 build process in a very mysterious way - setup.py ends up using -L/usr/lib/python2.5/config instead of -L. for libpython2.5.so, which is obviously wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&group_id=5470 From noreply at sourceforge.net Tue Sep 12 11:38:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 02:38:27 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-05 18:11 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2006-09-12 09:38 Message: Logged In: YES user_id=1262199 I submitted this mostly as a demonstration. I don't think the approach is necessarily suitable for a final implementation because of the use of utf-8 as an intermediate representation and the price of the conversions that keep happening. But perhaps this is the way to go, if we consider utf-8 to be a stage-1 default file system encoding for win32. I also agree that 4 is probably the most sensible approach. What about discrepancies between e.g. linux and windows then, when including from a non-trivial path? On linux we would get utf-8, on windows unicode? 1) would actually make a lot of sense, only in my experience this tends to lead to a kind of unicode-hell since a program touched by one unicode object tends to have it percolating down into every corner. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-09 12:31 Message: Logged In: YES user_id=21627 First: Do you want to continue to work on this, or do you consider this just "demonstration code" (i.e. not contributed for inclusion in Python), hoping that somebody else implements this feature? I think the behavior of __file__ must be more consistent across platforms, and the selected behaviour must be documented somewhere. Several definitions of "consistent behavior" come to mind: 1. __file__ is always a Unicode string 2. __file__ is a byte string if its ASCII, else Unicode 3. __file__ is a byte string if its in the system encoding, else Unicode 4. __file__ is a byte string if its in the file system encoding, else Unicode. The documentation needs to be updated in several places, e.g. also for inspect.getfile. I would expect that pydoc would also need to be updated. Selecting from the options above: I believe 4 is most compatible with previous versions; 1 and 2 are most convenient to work with in applications like pydoc which have to generate HTML (1 is easier to work with, 2 is more compatible with previous versions). ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2006-09-09 11:38 Message: Logged In: YES user_id=1262199 >From the top of my head, it is now unicode. I consider trying to convert it back to the default encoding but decided not to to keep the patch brief. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-08 21:03 Message: Logged In: YES user_id=21627 What is the value of the __file__ attribute of a module when this patch is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Tue Sep 12 13:29:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 04:29:03 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-06 04:11 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-09-12 21:29 Message: Logged In: YES user_id=29957 There's a variety of modules in the standard library that reference __file__ - if it's potentially going to be a unicode string, these are going to need to be checked, as are their callers :-/ (Now that I've looked closer at some of the issues, I'm extremely glad this didn't go into 2.5 final at this late stage) ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2006-09-12 19:38 Message: Logged In: YES user_id=1262199 I submitted this mostly as a demonstration. I don't think the approach is necessarily suitable for a final implementation because of the use of utf-8 as an intermediate representation and the price of the conversions that keep happening. But perhaps this is the way to go, if we consider utf-8 to be a stage-1 default file system encoding for win32. I also agree that 4 is probably the most sensible approach. What about discrepancies between e.g. linux and windows then, when including from a non-trivial path? On linux we would get utf-8, on windows unicode? 1) would actually make a lot of sense, only in my experience this tends to lead to a kind of unicode-hell since a program touched by one unicode object tends to have it percolating down into every corner. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-09 22:31 Message: Logged In: YES user_id=21627 First: Do you want to continue to work on this, or do you consider this just "demonstration code" (i.e. not contributed for inclusion in Python), hoping that somebody else implements this feature? I think the behavior of __file__ must be more consistent across platforms, and the selected behaviour must be documented somewhere. Several definitions of "consistent behavior" come to mind: 1. __file__ is always a Unicode string 2. __file__ is a byte string if its ASCII, else Unicode 3. __file__ is a byte string if its in the system encoding, else Unicode 4. __file__ is a byte string if its in the file system encoding, else Unicode. The documentation needs to be updated in several places, e.g. also for inspect.getfile. I would expect that pydoc would also need to be updated. Selecting from the options above: I believe 4 is most compatible with previous versions; 1 and 2 are most convenient to work with in applications like pydoc which have to generate HTML (1 is easier to work with, 2 is more compatible with previous versions). ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2006-09-09 21:38 Message: Logged In: YES user_id=1262199 >From the top of my head, it is now unicode. I consider trying to convert it back to the default encoding but decided not to to keep the patch brief. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-09 07:03 Message: Logged In: YES user_id=21627 What is the value of the __file__ attribute of a module when this patch is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Tue Sep 12 21:35:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 12:35:42 -0700 Subject: [Patches] [ python-Patches-1557390 ] datetime's strftime limits strings to 127 chars Message-ID: Patches item #1557390, was opened at 2006-09-12 15:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557390&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: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: See bug http://python.org/sf/1556784 By putting the length into a char, wrap_strftime() restricts the format string to be 127 characters long. This patch removes that restriction, but using Py_ssize_t. Test included. Patch is against release25-maint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557390&group_id=5470 From noreply at sourceforge.net Tue Sep 12 22:17:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 13:17:55 -0700 Subject: [Patches] [ python-Patches-1552880 ] Unicode Imports Message-ID: Patches item #1552880, was opened at 2006-09-05 20:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Kristj?n Valur (krisvale) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode Imports Initial Comment: This patch modifies the import mechanism to fully support unicode pathnames on Windows. It does this by first converting each member of sys.path to utf-8. strings are encoded using the current locale. The whole of the import logic is then unchanged and works on the utf-8 strings as though they were regular ascii strings in the current locale. Only when file operations are done, such as stat() and open(), do we then convert from utf-8 back to unicode and use the Windows unicode APIs for the job. This is also done when initializing Module objects. This approach has the benefit of being of having a low impact on the importing logic, and is thus easy to verify. There is however some overhead with the conversions. At CCP games we used this approach, backported to python 2.3, to get unicode imports working for our game, EVE Online, and thereby solving installation issues in the far east. This patch is submitted as demonstration code to the python community. I would like to see unicode fully supported in 2.6. Cheers, Kristj??n ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-09-12 22:17 Message: Logged In: YES user_id=21627 krisvale: indeed, option 4 is platform dependent. Notice that on Linux, the file system encoding won't necessarily be UTF-8. Instead, the value depends on the locale, so it may be latin-1, latin-9, gb2312, ... This makes it even more dependent on the platform, and even the current user being logged in (such is life with locale-based approaches; the same is mostly true for Windows: "mbcs" can mean nearly anything). option 1) is Py3k-safe, where path names will be Unicode strings always. As you say, Unicode is a virulent type, so this approach would need a wide consensus. I'm personally leaning towards option 2: it is nearly backwards compatible, except for obscure cases where people have mbcs-encodable entries in sys.path already, and it is independent of manipulations of the system encoding. I also think that processing of PYTHONPATH should take Unicode into account, i.e. we should use _wgetenv to access PYTHONPATH in 2.6. That would make the feature truly useful, as then people could actually set sys.path to non-mbcs directlories from the outside. Notice that W9x support can be dropped in 2.6, so a W9x-compatible solution won't be required. In any case, I'd like to encourage you to continue working on this issue. I, too, like to see it in 2.6, but I did so ever since 2.1 or so (before PEP 277 was implemented), and it was wishful thinking. Somebody has to take action, and it is likely that it won't one of the past regular contributors (or else they had contributed it long ago - although I think Thomas Heller had something working at one point). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-09-12 13:29 Message: Logged In: YES user_id=29957 There's a variety of modules in the standard library that reference __file__ - if it's potentially going to be a unicode string, these are going to need to be checked, as are their callers :-/ (Now that I've looked closer at some of the issues, I'm extremely glad this didn't go into 2.5 final at this late stage) ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2006-09-12 11:38 Message: Logged In: YES user_id=1262199 I submitted this mostly as a demonstration. I don't think the approach is necessarily suitable for a final implementation because of the use of utf-8 as an intermediate representation and the price of the conversions that keep happening. But perhaps this is the way to go, if we consider utf-8 to be a stage-1 default file system encoding for win32. I also agree that 4 is probably the most sensible approach. What about discrepancies between e.g. linux and windows then, when including from a non-trivial path? On linux we would get utf-8, on windows unicode? 1) would actually make a lot of sense, only in my experience this tends to lead to a kind of unicode-hell since a program touched by one unicode object tends to have it percolating down into every corner. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-09 14:31 Message: Logged In: YES user_id=21627 First: Do you want to continue to work on this, or do you consider this just "demonstration code" (i.e. not contributed for inclusion in Python), hoping that somebody else implements this feature? I think the behavior of __file__ must be more consistent across platforms, and the selected behaviour must be documented somewhere. Several definitions of "consistent behavior" come to mind: 1. __file__ is always a Unicode string 2. __file__ is a byte string if its ASCII, else Unicode 3. __file__ is a byte string if its in the system encoding, else Unicode 4. __file__ is a byte string if its in the file system encoding, else Unicode. The documentation needs to be updated in several places, e.g. also for inspect.getfile. I would expect that pydoc would also need to be updated. Selecting from the options above: I believe 4 is most compatible with previous versions; 1 and 2 are most convenient to work with in applications like pydoc which have to generate HTML (1 is easier to work with, 2 is more compatible with previous versions). ---------------------------------------------------------------------- Comment By: Kristj?n Valur (krisvale) Date: 2006-09-09 13:38 Message: Logged In: YES user_id=1262199 >From the top of my head, it is now unicode. I consider trying to convert it back to the default encoding but decided not to to keep the patch brief. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-08 23:03 Message: Logged In: YES user_id=21627 What is the value of the __file__ attribute of a module when this patch is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1552880&group_id=5470 From noreply at sourceforge.net Wed Sep 13 00:21:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Sep 2006 15:21:57 -0700 Subject: [Patches] [ python-Patches-1557515 ] Add RLIMIT_SBSIZE to resource module Message-ID: Patches item #1557515, was opened at 2006-09-12 15: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=1557515&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: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Add RLIMIT_SBSIZE to resource module Initial Comment: The following patch adds the RLIMIT_SBSIZE constant to the resource module (for setting socket buffer limits). Used in FreeBSD, and possibly other operating systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557515&group_id=5470 From noreply at sourceforge.net Wed Sep 13 14:54:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 05:54:11 -0700 Subject: [Patches] [ python-Patches-1557890 ] missing imports ctypes in documentation examples Message-ID: Patches item #1557890, was opened at 2006-09-13 12: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=1557890&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: Daniele Varrazzo (dvarrazzo) Assigned to: Nobody/Anonymous (nobody) Summary: missing imports ctypes in documentation examples Initial Comment: The attached patch fixes a couple of missing imports in ctypes documentation examples. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 From noreply at sourceforge.net Wed Sep 13 17:23:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 08:23:41 -0700 Subject: [Patches] [ python-Patches-1557890 ] missing imports ctypes in documentation examples Message-ID: Patches item #1557890, was opened at 2006-09-13 14:54 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&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: Daniele Varrazzo (dvarrazzo) >Assigned to: Thomas Heller (theller) Summary: missing imports ctypes in documentation examples Initial Comment: The attached patch fixes a couple of missing imports in ctypes documentation examples. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 From noreply at sourceforge.net Wed Sep 13 23:16:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Sep 2006 14:16:24 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&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: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 06:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-12 04:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-08 02:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 14:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Thu Sep 14 09:04:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Sep 2006 00:04:50 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&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: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 16:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 06:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-12 04:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-08 02:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 14:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Fri Sep 15 13:01:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 04:01:43 -0700 Subject: [Patches] [ python-Patches-1559219 ] Practical ctypes example Message-ID: Patches item #1559219, was opened at 2006-09-15 11:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&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: leppton (leppton) Assigned to: Nobody/Anonymous (nobody) Summary: Practical ctypes example Initial Comment: Ctypes module documentation can be little hard to grasp, so I wrote a practical example that reads all function names from dll export directory. It has structures, pointer arithmetic, and function prototype with default parameters. Maybe it fits somewhere in documentation... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 From noreply at sourceforge.net Fri Sep 15 14:59:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 05:59:10 -0700 Subject: [Patches] [ python-Patches-1559298 ] test_popen fails on Windows if installed to "Program Files" Message-ID: Patches item #1559298, was opened at 2006-09-15 14: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=1559298&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: test_popen fails on Windows if installed to "Program Files" Initial Comment: test_popen fails in 2.5c2. The reason is that popen invokes cmd.exe /c "c:\program files\python25\python.exe" -c "import sys;print sys.argv" cmd.exe does not support that syntax, and gives an error (which silently disappears); the pipe read then returns an empty string. This problem exists atleast since Python 2.3. To fix this, cmd.exe needs to be invoked as cmd.exe /c "c:\program files\python25\python.exe" -c "import sys;print sys.argv" The attached patch fixes this by always wrapping the command line with an addition pair of quotes. It's not clear to me whether this can go into 2.5.1: an application may already work around this problem by passing extra quotes to popen, which would then break if popen adds even more quotes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559298&group_id=5470 From noreply at sourceforge.net Fri Sep 15 17:43:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 08:43:38 -0700 Subject: [Patches] [ python-Patches-1559413 ] test_cmd_line fails on Windows Message-ID: Patches item #1559413, was opened at 2006-09-15 17:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559413&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: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: test_cmd_line fails on Windows Initial Comment: test_cmd_line fails in 2.5c2 if Python is installed into a directory with spaces in its name. This is a shallow problem, and can be fixe with attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559413&group_id=5470 From noreply at sourceforge.net Fri Sep 15 17:52:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 08:52:07 -0700 Subject: [Patches] [ python-Patches-1559219 ] Practical ctypes example Message-ID: Patches item #1559219, was opened at 2006-09-15 13:01 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&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: leppton (leppton) >Assigned to: Thomas Heller (theller) Summary: Practical ctypes example Initial Comment: Ctypes module documentation can be little hard to grasp, so I wrote a practical example that reads all function names from dll export directory. It has structures, pointer arithmetic, and function prototype with default parameters. Maybe it fits somewhere in documentation... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 From noreply at sourceforge.net Fri Sep 15 19:13:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 10:13:51 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-30 21:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&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: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-15 13:13 Message: Logged In: YES user_id=6380 I see. The Grammar should simply make the NAME after the '*' optional. Shouldn't be too hard to fix should it? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 03:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-13 17:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-11 15:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-07 13:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 01:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Sat Sep 16 00:36:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Sep 2006 15:36:30 -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 (Comment added) made by martineau 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: Closed >Resolution: Duplicate 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) ---------------------------------------------------------------------- >Comment By: Mat Martineau (martineau) Date: 2006-09-15 15:36 Message: Logged In: YES user_id=1094573 See bug 775964. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1510987&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:37:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:37:00 -0700 Subject: [Patches] [ python-Patches-1557515 ] Add RLIMIT_SBSIZE to resource module Message-ID: Patches item #1557515, was opened at 2006-09-13 00:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557515&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: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Add RLIMIT_SBSIZE to resource module Initial Comment: The following patch adds the RLIMIT_SBSIZE constant to the resource module (for setting socket buffer limits). Used in FreeBSD, and possibly other operating systems. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:37 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as r51897 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557515&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:40:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:40:42 -0700 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-19 03:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&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: Out of Date Priority: 6 Submitted By: baus (cbaus) Assigned to: Anthony Baxter (anthonybaxter) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:40 Message: Logged In: YES user_id=21627 typesmodule was already added. Can you please update the subversion, and regenerate the patch adding _socket? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 22:14 Message: Logged In: YES user_id=33168 The patch doesn't apply. I don't have a windows box, so I can't even test it. All I can do is apply. ---------------------------------------------------------------------- Comment By: baus (cbaus) Date: 2006-09-05 22:07 Message: Logged In: YES user_id=1579156 The patch doesn't apply cleanly, or adding this module to the project doesn't apply? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 04:46 Message: Logged In: YES user_id=33168 This patch doesn't apply to 2.5. 2.6 is probably the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Sat Sep 16 19:41:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 10:41:38 -0700 Subject: [Patches] [ python-Patches-1540617 ] Use Py_ssize_t for rangeobject members Message-ID: Patches item #1540617, was opened at 2006-08-15 15:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540617&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use Py_ssize_t for rangeobject members Initial Comment: Use Py_ssize_t for rangeobject start, step and len and rangeiterobject's index, start, step and length. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-16 19:41 Message: Logged In: YES user_id=21627 This might be superseded by 1546078 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540617&group_id=5470 From noreply at sourceforge.net Sat Sep 16 21:43:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 16 Sep 2006 12:43:28 -0700 Subject: [Patches] [ python-Patches-1457227 ] timestamp() method for datetime objects Message-ID: Patches item #1457227, was opened at 2006-03-23 22:06 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&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: Rejected Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp() method for datetime objects Initial Comment: This patch adds a timestamp() method to datetime objects. It is equivalent to: time.mktime(self.timetuple()) I pulled out the dstflag calculation code from datetime_timetuple into a new function, get_dstflag, so that datetime_timestamp can make use of the same code. The patch also includes updates to the datetime documentation, and a simple unit test. ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2006-09-16 21:43 Message: Logged In: YES user_id=221678 I know this is closed... I think it would be helpful to either 1) add a description to the documentation of how to convert back, explaining the timezone story 2) add a timestamp() function that takes a timezone parameter ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 23:41 Message: Logged In: YES user_id=6380 Well, that they both exist implies that the linkage is ambiguous... I think it's just not worth the new API given that it's (as you admit) just a shorthand for two other calls. There's also the problem that the range for timestamps is much smaller than the range of datetime -- this isn't a problem for .[utc]fromtimestamp() but is a problem for the reverse API. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2006-03-23 23:37 Message: Logged In: YES user_id=186532 The .fromtimestamp and .utcfromtimestamp class methods already imply this linkage, don't they? What if timestamp() only works if the datetime object isn't "naive"? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 22:23 Message: Logged In: YES user_id=6380 I'm against this functionality. It suggests an linkage between the "naive" (timezone-unaware) time carried in the datetime object, and the UTC space that posix timestamps represent. The entire point of the datetime type (unless an explicit tzinfo is passed) is that it doesn't know which timezone it represents. When you call time.mktime(self.timetuple()), you as the application make the determination that the timetuple (which is still tz-unaware!) represents your current local time. That's a fine decision for the app to make. But I don't think users should be lured into believing there's an equivalency inherent in the datetime type -- there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 From noreply at sourceforge.net Mon Sep 18 12:15:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 03:15:40 -0700 Subject: [Patches] [ python-Patches-1560617 ] pyclbr reports different module for Class and Function Message-ID: Patches item #1560617, was opened at 2006-09-18 10: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=1560617&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: Peter Otten (potten) Assigned to: Nobody/Anonymous (nobody) Summary: pyclbr reports different module for Class and Function Initial Comment: Starting with Python 2.4 pyclbr gives the qualified module name, but only for classes, not functions: >>> import pyclbr >>> for obj in pyclbr.readmodule_ex("test.test_pyclbr").values(): ... print ["func", "class"][isinstance(obj, pyclbr.Class)], obj.name, obj.module ... func test_main test_pyclbr class PyclbrTest test.test_pyclbr The fix is simple, see attached diffs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560617&group_id=5470 From noreply at sourceforge.net Mon Sep 18 14:23:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Sep 2006 05:23:28 -0700 Subject: [Patches] [ python-Patches-1560695 ] Exec stacks in python 2.5 Message-ID: Patches item #1560695, was opened at 2006-09-18 12:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Exec stacks in python 2.5 Initial Comment: Python 2.5 contains executable stacks. Attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 From noreply at sourceforge.net Wed Sep 20 08:26:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Sep 2006 23:26:59 -0700 Subject: [Patches] [ python-Patches-1560695 ] Exec stacks in python 2.5 Message-ID: Patches item #1560695, was opened at 2006-09-18 14:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Exec stacks in python 2.5 Initial Comment: Python 2.5 contains executable stacks. Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 08:26 Message: Logged In: YES user_id=21627 Can you please elaborate? What is an "executable stack", why does Python have one, why is that bad, and how does your patch fix that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 From noreply at sourceforge.net Wed Sep 20 13:58:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 04:58:48 -0700 Subject: [Patches] [ python-Patches-1560695 ] Exec stacks in python 2.5 Message-ID: Patches item #1560695, was opened at 2006-09-18 12:23 Message generated for change (Comment added) made by masterdriverz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Exec stacks in python 2.5 Initial Comment: Python 2.5 contains executable stacks. Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Chaza (masterdriverz) Date: 2006-09-20 11:58 Message: Logged In: YES user_id=1096685 It is probably best summed up here -> http://www.gentoo.org/proj/en/hardened/gnu-stack.xml but put simply, executable stacks don't work on hardened systems. The simplest way to fix them is to explicitly tell gcc to compile libraries without executable stacks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 06:26 Message: Logged In: YES user_id=21627 Can you please elaborate? What is an "executable stack", why does Python have one, why is that bad, and how does your patch fix that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 From noreply at sourceforge.net Wed Sep 20 19:05:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 10:05:23 -0700 Subject: [Patches] [ python-Patches-1560695 ] Exec stacks in python 2.5 Message-ID: Patches item #1560695, was opened at 2006-09-18 14:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Exec stacks in python 2.5 Initial Comment: Python 2.5 contains executable stacks. Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 19:05 Message: Logged In: YES user_id=21627 Ah, so the patch doesn't actually fix that Python 2.5 contains executable stacks. It rather makes it execute successfully on a hardened system. Still, I don't understand what you mean by "Python contains executable stacks". Where does it do so? And what precisely breaks on a hardened system when Python is running on it? ---------------------------------------------------------------------- Comment By: Chaza (masterdriverz) Date: 2006-09-20 13:58 Message: Logged In: YES user_id=1096685 It is probably best summed up here -> http://www.gentoo.org/proj/en/hardened/gnu-stack.xml but put simply, executable stacks don't work on hardened systems. The simplest way to fix them is to explicitly tell gcc to compile libraries without executable stacks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 08:26 Message: Logged In: YES user_id=21627 Can you please elaborate? What is an "executable stack", why does Python have one, why is that bad, and how does your patch fix that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 From noreply at sourceforge.net Wed Sep 20 22:47:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Sep 2006 13:47:22 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 20:03 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&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: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-20 22:47 Message: Logged In: YES user_id=580910 Timeout with REUSADDR tends to be several minutes. seems to indicate that SO_REUSEADDR behaves unlike what unix does: two applications can bind to the same port if one of them uses SO_REUSEADDR. Picking the first available port and disabling SO_REUSEADDR should therefore both enable multi-process mode and solve the delay issue kbk is having during debugging. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-28 21:48 Message: Logged In: YES user_id=149084 Timeout might have been a whole minute. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-28 21:44 Message: Logged In: YES user_id=149084 I don't mean to be derogatory by calling it a hack! Hacks can be very practical and useful, but they are often not 100% reliable. I'm only referring to the port selection part of the patch. Regarding REUSEADDR, if it is not set True there is a timeout before the listening connection can be set up again on the same socket. As I recollect, it's ten sec, and so very annoying when restarting IDLE especially during development. Guido clued me in on REUSEADDR, which solved the problem. According to the below links, it's only operative when the socket is in the TIME_WAIT state, and that should not be the case in the W2K overlapping socket situation. http://www.unixguide.net/network/socketfaq/4.5.shtml http://www.unixguide.net/network/socketfaq/2.7.shtml IDLE discussion should be on IDLE-dev unless it's something which affects the Python implementation or changes the installation, i.e. how .py is bound on Windows. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-27 08:54 Message: Logged In: YES user_id=1330769 My patch is not so much a hack, it's actually a more optimal implementation, with or without the Windows issue. It just also happens to make port collision very rare ;) Aren't coincidences wonderful? Anyways, I remember seeing something about "reuse address" when binding sockets... ah, here it is. Check out SocketServer.py: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) And this comment in BaseHTTPServer.py: allow_reuse_address = 1 # Seems to make sense in testing environment Could socket.SO_REUSEADDR be the cause? What does it default to? Maybe its implementation on Windows is broken? (Probably not, but still worth checking.) Maybe we should get the discussion up and running again in Python-Dev or c.l.p... ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-27 05:05 Message: Logged In: YES user_id=149084 On Windows 2000, at least, when a collision occurs there is a significant (30%?) chance that the late arrival will get a listening connection. Then both sets of processes merrily communicate on the same socket, apparently w/o mutual corruption. At least that's the way it seemed to me last time I looked. I can't put much faith in a situation like that. However, your patch 1529142, though a hack, may be practical, at least for now. 2.6. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-26 19:31 Message: Logged In: YES user_id=1330769 I agree that IDLE must have a no-subprocess mode, since it has its uses. Still, I feel these uses are relatively isoteric, so while the option should exist as a command line option, it shouldn't usually be used by non-developers. On systems without networking trying to use sockets will fail, and IDLE should detect this and fall-back to no-subprocess mode automatically. (Another item on the TODO list...) Well, we could "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as you say, erratic. Also, if a collision happens the listening socket won't recieve a connection, and accept() will timeout. After this we can continue trying other ports. I submitted my implementation as a separate patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-25 21:40 Message: Logged In: YES user_id=149084 There are a couple of reasons: some systems don't have networking installed, and running w/o the subprocess causes the debugger to work slightly differently: it is possible to debug IDLE itself. It is surprising that it was possible to run IDLE in either mode w/o mucking up the code too badly. But there is one major problem: on Windows, it's possible to start more than one listener on a port. I haven't been able to track this down, it's somewhat erratic. Given the problems on Windows with stuck subprocesses, I'm loath to go to multiple instances of IDLE w/o fixing the multiple listener problem with its collisions. I certainly agree with you that it would be very desireable not to use the -n switch in the "edit with IDLE" binding. And I also agree about the efficacy of the subprocess, that's why we went to all the effort on IDLEfork. https://sourceforge.net/tracker/ index.php?func=detail&aid=661363&group_id=9579&atid=309579 Maybe we can get this fixed in 2.6. It's way too risky to attempt it in 2.5 and it's a new feature. Could you add your patch so I can look at it? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 15:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 14:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 06:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Thu Sep 21 13:51:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 04:51:38 -0700 Subject: [Patches] [ python-Patches-1560695 ] Exec stacks in python 2.5 Message-ID: Patches item #1560695, was opened at 2006-09-18 12:23 Message generated for change (Comment added) made by masterdriverz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Exec stacks in python 2.5 Initial Comment: Python 2.5 contains executable stacks. Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Chaza (masterdriverz) Date: 2006-09-21 11:51 Message: Logged In: YES user_id=1096685 No, sorry I've badly described the situation in the previous post. This patch explicitly tells GCC to not make the stack executable for Python-2.5c1/Modules/_ctypes/libffi/src/x86/sysv.S , this means that it should execute successfully on a hardened system. Without this patch, GCC guesses (incorrectly) that sysv.o requires an executable stack, and sets it accordingly. This can cause execution to fail if Exec Shield is enabled on hardened systems. Basically its just better practice to explicitly mark whether assembly code needs an executable stack or not, and for the most part, it doesn't. For more info (since I'm not brilliant at explaining this) see: http://people.redhat.com/drepper/nonselsec.pdf (particularly Appendix A and Exec Shield) http://people.redhat.com/drepper/selinux-mem.html http://www.gentoo.org/proj/en/hardened/gnu-stack.xml or drop into #gentoo-hardened on Freenode. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 17:05 Message: Logged In: YES user_id=21627 Ah, so the patch doesn't actually fix that Python 2.5 contains executable stacks. It rather makes it execute successfully on a hardened system. Still, I don't understand what you mean by "Python contains executable stacks". Where does it do so? And what precisely breaks on a hardened system when Python is running on it? ---------------------------------------------------------------------- Comment By: Chaza (masterdriverz) Date: 2006-09-20 11:58 Message: Logged In: YES user_id=1096685 It is probably best summed up here -> http://www.gentoo.org/proj/en/hardened/gnu-stack.xml but put simply, executable stacks don't work on hardened systems. The simplest way to fix them is to explicitly tell gcc to compile libraries without executable stacks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-20 06:26 Message: Logged In: YES user_id=21627 Can you please elaborate? What is an "executable stack", why does Python have one, why is that bad, and how does your patch fix that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560695&group_id=5470 From noreply at sourceforge.net Thu Sep 21 14:01:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Sep 2006 05:01:50 -0700 Subject: [Patches] [ python-Patches-1562825 ] Python 2.5 fails with -Wl, --as-needed in LDFLAGS Message-ID: Patches item #1562825, was opened at 2006-09-21 12:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1562825&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 fails with -Wl,--as-needed in LDFLAGS Initial Comment: Python 2.5 fails at final linking with this error: i686-pc-linux-gnu-ranlib libpython2.5.a i686-pc-linux-gnu-gcc -pthread -Wl,--as-needed -Xlinker -export-dynamic -o python \ Modules/python.o \ -L. -lpython2.5 -lpthread -ldl -lutil -L/usr/lib -lz -lm ./libpython2.5.so: undefined reference to `inflateEnd' ./libpython2.5.so: undefined reference to `deflate' ./libpython2.5.so: undefined reference to `deflateInit_' ./libpython2.5.so: undefined reference to `inflateInit2_' ./libpython2.5.so: undefined reference to `inflate' ./libpython2.5.so: undefined reference to `crc32' ./libpython2.5.so: undefined reference to `deflateEnd' ./libpython2.5.so: undefined reference to `deflateCopy' ./libpython2.5.so: undefined reference to `deflateInit2_' ./libpython2.5.so: undefined reference to `adler32' ./libpython2.5.so: undefined reference to `inflateCopy' collect2: ld returned 1 exit status make: *** [python] Error 1 !!! ERROR: dev-lang/python-2.5_rc1 failed. Attached patch fixes this, by changing the linking order from "Modules/python.o -L. -lpython2.5 -lpthread -ldl -lutil -L/usr/lib -lz -lm" to "Modules/python.o -lpython2.5 -L. -lpthread -ldl -lutil -L/usr/lib -lz -lm" , basically swapping "-L. -lpython2.5" around. The patch edits configure.in and swaps them for Linux, BSD and SunOS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1562825&group_id=5470 From noreply at sourceforge.net Sat Sep 23 03:59:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 18:59:35 -0700 Subject: [Patches] [ python-Patches-1563842 ] platform.py support for IronPython Message-ID: Patches item #1563842, was opened at 2006-09-23 11: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=1563842&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: Anthony Baxter (anthonybaxter) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.py support for IronPython Initial Comment: The following patch supplies minimal support for IronPython in platform.py - it makes the sys.version parsing not choke and die. There's a bunch of missing information from IronPython's sys.version string, not much that can be done there. Should platform.py grow an 'implementation' option, so it can detect whether it's IronPython, CPython, Jython, or something else? Patch is against svn trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&group_id=5470 From noreply at sourceforge.net Sat Sep 23 04:05:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 19:05:06 -0700 Subject: [Patches] [ python-Patches-1563844 ] pybench support for IronPython Message-ID: Patches item #1563844, was opened at 2006-09-23 12:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563844&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: Anthony Baxter (anthonybaxter) Assigned to: M.-A. Lemburg (lemburg) Summary: pybench support for IronPython Initial Comment: The following patch to pybench/pybench.py makes it work on IronPython. IronPython returns NotImplementedError for both gc.disable() and sys.setcheckinterval() - catch that and report it. This also requires patch #1563842, which fixes platform.py for IronPython. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563844&group_id=5470 From noreply at sourceforge.net Sat Sep 23 04:31:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Sep 2006 19:31:26 -0700 Subject: [Patches] [ python-Patches-1563844 ] pybench support for IronPython Message-ID: Patches item #1563844, was opened at 2006-09-23 12:05 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563844&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: Anthony Baxter (anthonybaxter) Assigned to: M.-A. Lemburg (lemburg) Summary: pybench support for IronPython Initial Comment: The following patch to pybench/pybench.py makes it work on IronPython. IronPython returns NotImplementedError for both gc.disable() and sys.setcheckinterval() - catch that and report it. This also requires patch #1563842, which fixes platform.py for IronPython. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-09-23 12:31 Message: Logged In: YES user_id=29957 Sigh. Somewhere I dropped the magic 'print' statements. Fixed patch applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563844&group_id=5470 From noreply at sourceforge.net Sun Sep 24 16:13:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 07:13:07 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 15: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=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Sun Sep 24 19:25:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Sep 2006 10:25:26 -0700 Subject: [Patches] [ python-Patches-1562825 ] Python 2.5 fails with -Wl, --as-needed in LDFLAGS Message-ID: Patches item #1562825, was opened at 2006-09-21 14:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1562825&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: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 fails with -Wl,--as-needed in LDFLAGS Initial Comment: Python 2.5 fails at final linking with this error: i686-pc-linux-gnu-ranlib libpython2.5.a i686-pc-linux-gnu-gcc -pthread -Wl,--as-needed -Xlinker -export-dynamic -o python \ Modules/python.o \ -L. -lpython2.5 -lpthread -ldl -lutil -L/usr/lib -lz -lm ./libpython2.5.so: undefined reference to `inflateEnd' ./libpython2.5.so: undefined reference to `deflate' ./libpython2.5.so: undefined reference to `deflateInit_' ./libpython2.5.so: undefined reference to `inflateInit2_' ./libpython2.5.so: undefined reference to `inflate' ./libpython2.5.so: undefined reference to `crc32' ./libpython2.5.so: undefined reference to `deflateEnd' ./libpython2.5.so: undefined reference to `deflateCopy' ./libpython2.5.so: undefined reference to `deflateInit2_' ./libpython2.5.so: undefined reference to `adler32' ./libpython2.5.so: undefined reference to `inflateCopy' collect2: ld returned 1 exit status make: *** [python] Error 1 !!! ERROR: dev-lang/python-2.5_rc1 failed. Attached patch fixes this, by changing the linking order from "Modules/python.o -L. -lpython2.5 -lpthread -ldl -lutil -L/usr/lib -lz -lm" to "Modules/python.o -lpython2.5 -L. -lpthread -ldl -lutil -L/usr/lib -lz -lm" , basically swapping "-L. -lpython2.5" around. The patch edits configure.in and swaps them for Linux, BSD and SunOS. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-24 19:25 Message: Logged In: YES user_id=21627 Can you please provide exact instructions on how to reproduce the problem? The patch looks wrong. If libpython2.5.so has references to libz, then it should be linked with libz itself (rather than linking the executable with libz). Notice that the procedure to create a shared libpython is mostly unmaintained and unsupported; so patches to improve it would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1562825&group_id=5470 From noreply at sourceforge.net Mon Sep 25 12:30:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 03:30:46 -0700 Subject: [Patches] [ python-Patches-1563842 ] platform.py support for IronPython Message-ID: Patches item #1563842, was opened at 2006-09-23 03:59 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&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: Anthony Baxter (anthonybaxter) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.py support for IronPython Initial Comment: The following patch supplies minimal support for IronPython in platform.py - it makes the sys.version parsing not choke and die. There's a bunch of missing information from IronPython's sys.version string, not much that can be done there. Should platform.py grow an 'implementation' option, so it can detect whether it's IronPython, CPython, Jython, or something else? Patch is against svn trunk. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-25 12:30 Message: Logged In: YES user_id=38388 Thanks. I'll install IronPython and see what else needs to be done. I've already added a few fixes to make Jython play nice with platform.py that I'll check in as well. And yes: I'll add a python_implementation() function that returns 'CPython', 'Jython' and 'IronPython' as appropriate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1563842&group_id=5470 From noreply at sourceforge.net Mon Sep 25 12:58:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 03:58:01 -0700 Subject: [Patches] [ python-Patches-1564981 ] tarfile depends on undocumented behaviour Message-ID: Patches item #1564981, was opened at 2006-09-25 19: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=1564981&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: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile depends on undocumented behaviour Initial Comment: CPython currently treats an argument to int() or long() when base is specified as null-terminated strings, but this isn't documented AFAIK. i.e. int('0777\0', 8) works. tarfile depends on this behaviour, which breaks IronPython 1.0. Attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564981&group_id=5470 From noreply at sourceforge.net Mon Sep 25 14:06:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Sep 2006 05:06:45 -0700 Subject: [Patches] [ python-Patches-1565037 ] use LSB version information to detect a platform Message-ID: Patches item #1565037, was opened at 2006-09-25 14:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1565037&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: use LSB version information to detect a platform Initial Comment: reported at https://launchpad.net/bugs/54692 LSB conformant distributions should use lsb_version to get the platform information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1565037&group_id=5470 From noreply at sourceforge.net Wed Sep 27 01:53:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Sep 2006 16:53:01 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 08:13 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-26 17:53 Message: Logged In: YES user_id=12364 I've looked over the patch, although I haven't tested it. I have the following suggestions: * Needs documentation explaining the signal weirdness (may drop signals, may delay indefinitely, new handlers may get signals intended for old, etc) * Needs to be explicit that users must only poll/select to check for readability of the pipe, NOT read from it * The comment for is_tripped refers to sigcheck(), which doesn't exist * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. * In signal_hander() sizeof(signum_c) is inherently 1. ;) * The set_nonblock macro doesn't check for errors from fcntl(). I'm not sure it's worth having a macro for that anyway. * Needs some documentation of the assumptions about read()/write() being memory barriers. * In check_signals() sizeof(signum) is inherently 1. * There's a blank line with tabs near the end of check_signals() ;) * PyErr_SetInterrupt() should use a compile-time check for SIGINT being within 0..UCHAR_MAX, assuming NSIG is ripped out entierly. * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Wed Sep 27 15:42:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 06:42:47 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 15:13 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 14:42 Message: Logged In: YES user_id=908 > * Needs documentation ... True, I'll try to add more documentation... > * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. I disagree. Creating an array of size UCHAR_MAX is just wasting memory. If you check the original python code, there's already fallback code to define NSIG if it's not already defined (if not defined, it could end up being defines as 64). > * In signal_hander() sizeof(signum_c) is inherently 1. ;) And? I occasionally hear horror stories of platforms where sizeof(char) != 1, I'm not taking any chances :) > * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. check_signals already bails out if that is the case. But in fact it bails out without setting the interrupt_occurred output parameter, so I fixed that. fcntl error checking... will work on it. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-27 00:53 Message: Logged In: YES user_id=12364 I've looked over the patch, although I haven't tested it. I have the following suggestions: * Needs documentation explaining the signal weirdness (may drop signals, may delay indefinitely, new handlers may get signals intended for old, etc) * Needs to be explicit that users must only poll/select to check for readability of the pipe, NOT read from it * The comment for is_tripped refers to sigcheck(), which doesn't exist * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. * In signal_hander() sizeof(signum_c) is inherently 1. ;) * The set_nonblock macro doesn't check for errors from fcntl(). I'm not sure it's worth having a macro for that anyway. * Needs some documentation of the assumptions about read()/write() being memory barriers. * In check_signals() sizeof(signum) is inherently 1. * There's a blank line with tabs near the end of check_signals() ;) * PyErr_SetInterrupt() should use a compile-time check for SIGINT being within 0..UCHAR_MAX, assuming NSIG is ripped out entierly. * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Wed Sep 27 16:34:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 07:34:42 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 15:13 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 15:34 Message: Logged In: YES user_id=908 and of course this > * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. is correct, good catch. New patch uploaded. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 14:42 Message: Logged In: YES user_id=908 > * Needs documentation ... True, I'll try to add more documentation... > * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. I disagree. Creating an array of size UCHAR_MAX is just wasting memory. If you check the original python code, there's already fallback code to define NSIG if it's not already defined (if not defined, it could end up being defines as 64). > * In signal_hander() sizeof(signum_c) is inherently 1. ;) And? I occasionally hear horror stories of platforms where sizeof(char) != 1, I'm not taking any chances :) > * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. check_signals already bails out if that is the case. But in fact it bails out without setting the interrupt_occurred output parameter, so I fixed that. fcntl error checking... will work on it. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-27 00:53 Message: Logged In: YES user_id=12364 I've looked over the patch, although I haven't tested it. I have the following suggestions: * Needs documentation explaining the signal weirdness (may drop signals, may delay indefinitely, new handlers may get signals intended for old, etc) * Needs to be explicit that users must only poll/select to check for readability of the pipe, NOT read from it * The comment for is_tripped refers to sigcheck(), which doesn't exist * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. * In signal_hander() sizeof(signum_c) is inherently 1. ;) * The set_nonblock macro doesn't check for errors from fcntl(). I'm not sure it's worth having a macro for that anyway. * Needs some documentation of the assumptions about read()/write() being memory barriers. * In check_signals() sizeof(signum) is inherently 1. * There's a blank line with tabs near the end of check_signals() ;) * PyErr_SetInterrupt() should use a compile-time check for SIGINT being within 0..UCHAR_MAX, assuming NSIG is ripped out entierly. * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Thu Sep 28 04:50:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 19:50:01 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 08:13 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-27 20:50 Message: Logged In: YES user_id=12364 Any compiler where sizeof(char) != 1 is *deeply* broken. In C, a byte isn't always 8 bits (if it uses bits at all!). It's possible for a char to take (for instance) 32 bits, but sizeof(char) will STILL return 1 in such a case. A mention of this in the wild is here: http://lkml.org/lkml/1998/1/22/4 If you find a compiler that's broken, I'd love to hear about it. :) # error Too many signals to fit on an unsigned char! Should be "in", not "on" :) A comment in signal_handler() about ignoring the return value of write() may be good. initsignal() should avoid not replace Py_signal_pipe/Py_signal_pipe_w if called a second time (which is possible, right?). If so, it should probably not set them until after setting non-blocking mode. check_signals() should not call PyEval_CallObject(Handlers[signum].func, ...) if func is NULL, which may happen after finisignal() clears it. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 08:34 Message: Logged In: YES user_id=908 and of course this > * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. is correct, good catch. New patch uploaded. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 07:42 Message: Logged In: YES user_id=908 > * Needs documentation ... True, I'll try to add more documentation... > * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. I disagree. Creating an array of size UCHAR_MAX is just wasting memory. If you check the original python code, there's already fallback code to define NSIG if it's not already defined (if not defined, it could end up being defines as 64). > * In signal_hander() sizeof(signum_c) is inherently 1. ;) And? I occasionally hear horror stories of platforms where sizeof(char) != 1, I'm not taking any chances :) > * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. check_signals already bails out if that is the case. But in fact it bails out without setting the interrupt_occurred output parameter, so I fixed that. fcntl error checking... will work on it. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-26 17:53 Message: Logged In: YES user_id=12364 I've looked over the patch, although I haven't tested it. I have the following suggestions: * Needs documentation explaining the signal weirdness (may drop signals, may delay indefinitely, new handlers may get signals intended for old, etc) * Needs to be explicit that users must only poll/select to check for readability of the pipe, NOT read from it * The comment for is_tripped refers to sigcheck(), which doesn't exist * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. * In signal_hander() sizeof(signum_c) is inherently 1. ;) * The set_nonblock macro doesn't check for errors from fcntl(). I'm not sure it's worth having a macro for that anyway. * Needs some documentation of the assumptions about read()/write() being memory barriers. * In check_signals() sizeof(signum) is inherently 1. * There's a blank line with tabs near the end of check_signals() ;) * PyErr_SetInterrupt() should use a compile-time check for SIGINT being within 0..UCHAR_MAX, assuming NSIG is ripped out entierly. * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Thu Sep 28 07:23:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Sep 2006 22:23:59 -0700 Subject: [Patches] [ python-Patches-1565037 ] use LSB version information to detect a platform Message-ID: Patches item #1565037, was opened at 2006-09-25 14:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1565037&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: Matthias Klose (doko) >Assigned to: M.-A. Lemburg (lemburg) Summary: use LSB version information to detect a platform Initial Comment: reported at https://launchpad.net/bugs/54692 LSB conformant distributions should use lsb_version to get the platform information. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 07:23 Message: Logged In: YES user_id=21627 MAL, can you please review this? If not, unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1565037&group_id=5470 From noreply at sourceforge.net Thu Sep 28 09:24:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 00:24:56 -0700 Subject: [Patches] [ python-Patches-1565037 ] use LSB version information to detect a platform Message-ID: Patches item #1565037, was opened at 2006-09-25 14:06 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1565037&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: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: use LSB version information to detect a platform Initial Comment: reported at https://launchpad.net/bugs/54692 LSB conformant distributions should use lsb_version to get the platform information. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-09-28 09:24 Message: Logged In: YES user_id=38388 Matthias, could you point me to a document defining the contents of that file ? Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-28 07:23 Message: Logged In: YES user_id=21627 MAL, can you please review this? If not, unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1565037&group_id=5470 From noreply at sourceforge.net Thu Sep 28 17:31:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 08:31:07 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 15:13 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- >Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-28 16:31 Message: Logged In: YES user_id=908 > ...sizeof(char) will STILL return 1 in such a case... Even if sizeof(char) == 1, 'sizeof(signum_c)' is much more readable than just a plain '1'. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-28 03:50 Message: Logged In: YES user_id=12364 Any compiler where sizeof(char) != 1 is *deeply* broken. In C, a byte isn't always 8 bits (if it uses bits at all!). It's possible for a char to take (for instance) 32 bits, but sizeof(char) will STILL return 1 in such a case. A mention of this in the wild is here: http://lkml.org/lkml/1998/1/22/4 If you find a compiler that's broken, I'd love to hear about it. :) # error Too many signals to fit on an unsigned char! Should be "in", not "on" :) A comment in signal_handler() about ignoring the return value of write() may be good. initsignal() should avoid not replace Py_signal_pipe/Py_signal_pipe_w if called a second time (which is possible, right?). If so, it should probably not set them until after setting non-blocking mode. check_signals() should not call PyEval_CallObject(Handlers[signum].func, ...) if func is NULL, which may happen after finisignal() clears it. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 15:34 Message: Logged In: YES user_id=908 and of course this > * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. is correct, good catch. New patch uploaded. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 14:42 Message: Logged In: YES user_id=908 > * Needs documentation ... True, I'll try to add more documentation... > * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. I disagree. Creating an array of size UCHAR_MAX is just wasting memory. If you check the original python code, there's already fallback code to define NSIG if it's not already defined (if not defined, it could end up being defines as 64). > * In signal_hander() sizeof(signum_c) is inherently 1. ;) And? I occasionally hear horror stories of platforms where sizeof(char) != 1, I'm not taking any chances :) > * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. check_signals already bails out if that is the case. But in fact it bails out without setting the interrupt_occurred output parameter, so I fixed that. fcntl error checking... will work on it. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-27 00:53 Message: Logged In: YES user_id=12364 I've looked over the patch, although I haven't tested it. I have the following suggestions: * Needs documentation explaining the signal weirdness (may drop signals, may delay indefinitely, new handlers may get signals intended for old, etc) * Needs to be explicit that users must only poll/select to check for readability of the pipe, NOT read from it * The comment for is_tripped refers to sigcheck(), which doesn't exist * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. * In signal_hander() sizeof(signum_c) is inherently 1. ;) * The set_nonblock macro doesn't check for errors from fcntl(). I'm not sure it's worth having a macro for that anyway. * Needs some documentation of the assumptions about read()/write() being memory barriers. * In check_signals() sizeof(signum) is inherently 1. * There's a blank line with tabs near the end of check_signals() ;) * PyErr_SetInterrupt() should use a compile-time check for SIGINT being within 0..UCHAR_MAX, assuming NSIG is ripped out entierly. * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Thu Sep 28 21:43:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Sep 2006 12:43:36 -0700 Subject: [Patches] [ python-Patches-1567274 ] doc changes for SMTP_SSL Message-ID: Patches item #1567274, was opened at 2006-09-28 19:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567274&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: Monty Taylor (sdirector) Assigned to: Nobody/Anonymous (nobody) Summary: doc changes for SMTP_SSL Initial Comment: This is related to patch 1282340, which I would like to see merged. Here is the patch again, but this time with changes made to the docs. Please let me know what I can do to move this forward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567274&group_id=5470 From noreply at sourceforge.net Fri Sep 29 14:58:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 05:58:56 -0700 Subject: [Patches] [ python-Patches-1567691 ] super() and instancemethod() shouldn't accept keyword args Message-ID: Patches item #1567691, was opened at 2006-09-29 14: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=1567691&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: super() and instancemethod() shouldn't accept keyword args Initial Comment: Constructors for the super() and instancemethod() types currently accept keyword arguments, but don't do anything with them. The patch fixes this by raising a TypeError when they are present. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567691&group_id=5470 From noreply at sourceforge.net Fri Sep 29 22:57:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 13:57:27 -0700 Subject: [Patches] [ python-Patches-1562825 ] Python 2.5 fails with -Wl, --as-needed in LDFLAGS Message-ID: Patches item #1562825, was opened at 2006-09-21 12:01 Message generated for change (Comment added) made by masterdriverz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1562825&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: Invalid Priority: 5 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 fails with -Wl,--as-needed in LDFLAGS Initial Comment: Python 2.5 fails at final linking with this error: i686-pc-linux-gnu-ranlib libpython2.5.a i686-pc-linux-gnu-gcc -pthread -Wl,--as-needed -Xlinker -export-dynamic -o python \ Modules/python.o \ -L. -lpython2.5 -lpthread -ldl -lutil -L/usr/lib -lz -lm ./libpython2.5.so: undefined reference to `inflateEnd' ./libpython2.5.so: undefined reference to `deflate' ./libpython2.5.so: undefined reference to `deflateInit_' ./libpython2.5.so: undefined reference to `inflateInit2_' ./libpython2.5.so: undefined reference to `inflate' ./libpython2.5.so: undefined reference to `crc32' ./libpython2.5.so: undefined reference to `deflateEnd' ./libpython2.5.so: undefined reference to `deflateCopy' ./libpython2.5.so: undefined reference to `deflateInit2_' ./libpython2.5.so: undefined reference to `adler32' ./libpython2.5.so: undefined reference to `inflateCopy' collect2: ld returned 1 exit status make: *** [python] Error 1 !!! ERROR: dev-lang/python-2.5_rc1 failed. Attached patch fixes this, by changing the linking order from "Modules/python.o -L. -lpython2.5 -lpthread -ldl -lutil -L/usr/lib -lz -lm" to "Modules/python.o -lpython2.5 -L. -lpthread -ldl -lutil -L/usr/lib -lz -lm" , basically swapping "-L. -lpython2.5" around. The patch edits configure.in and swaps them for Linux, BSD and SunOS. ---------------------------------------------------------------------- >Comment By: Chaza (masterdriverz) Date: 2006-09-29 20:57 Message: Logged In: YES user_id=1096685 Sorry for noise, I can't reproduce this anymore. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-24 17:25 Message: Logged In: YES user_id=21627 Can you please provide exact instructions on how to reproduce the problem? The patch looks wrong. If libpython2.5.so has references to libz, then it should be linked with libz itself (rather than linking the executable with libz). Notice that the procedure to create a shared libpython is mostly unmaintained and unsupported; so patches to improve it would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1562825&group_id=5470 From noreply at sourceforge.net Fri Sep 29 23:09:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Sep 2006 14:09:49 -0700 Subject: [Patches] [ python-Patches-1564547 ] Py_signal_pipe Message-ID: Patches item #1564547, was opened at 2006-09-24 08:13 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Py_signal_pipe Initial Comment: Problem: how to wakeup extension modules running poll() so that they can let python check for signals. Solution: use a pipe to communicate between signal handlers and main thread. The read end of the pipe can then be monitored by poll/select for input events and wake up poll(). As a side benefit, it avoids the usage of Py_AddPendingCall / Py_MakePendingCalls, which are patently not "async safe". All explained in this thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-29 15:09 Message: Logged In: YES user_id=12364 I'm concerned about the interface to PyOS_InterruptOccurred(). The original version peeked ahead for only that signal, and handled it manually. No need to report errors. The new version will first call arbitrary python functions to handle any earlier signals, then an arbitrary python function for the interrupt itself, and then will not report any errors they produce. It may not even get to the interrupt, even if one is waiting. I'm not sure PyOS_InterruptOccurred() is called when arbitrary python code is acceptable. I suspect it should be dropped entierly, in favour of a more robust API. Otoh, some of it appears quite crufty. One version in intrcheck.c lacks a return statement, invoking undefined behavior in C. One other concern I have is that signalmodule.c should never been unloaded, if loaded via dlopen. A delayed signal handler may reference it indefinitely. However, I see no sane way to enforce this. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-28 09:31 Message: Logged In: YES user_id=908 > ...sizeof(char) will STILL return 1 in such a case... Even if sizeof(char) == 1, 'sizeof(signum_c)' is much more readable than just a plain '1'. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-27 20:50 Message: Logged In: YES user_id=12364 Any compiler where sizeof(char) != 1 is *deeply* broken. In C, a byte isn't always 8 bits (if it uses bits at all!). It's possible for a char to take (for instance) 32 bits, but sizeof(char) will STILL return 1 in such a case. A mention of this in the wild is here: http://lkml.org/lkml/1998/1/22/4 If you find a compiler that's broken, I'd love to hear about it. :) # error Too many signals to fit on an unsigned char! Should be "in", not "on" :) A comment in signal_handler() about ignoring the return value of write() may be good. initsignal() should avoid not replace Py_signal_pipe/Py_signal_pipe_w if called a second time (which is possible, right?). If so, it should probably not set them until after setting non-blocking mode. check_signals() should not call PyEval_CallObject(Handlers[signum].func, ...) if func is NULL, which may happen after finisignal() clears it. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 08:34 Message: Logged In: YES user_id=908 and of course this > * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. is correct, good catch. New patch uploaded. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-09-27 07:42 Message: Logged In: YES user_id=908 > * Needs documentation ... True, I'll try to add more documentation... > * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. I disagree. Creating an array of size UCHAR_MAX is just wasting memory. If you check the original python code, there's already fallback code to define NSIG if it's not already defined (if not defined, it could end up being defines as 64). > * In signal_hander() sizeof(signum_c) is inherently 1. ;) And? I occasionally hear horror stories of platforms where sizeof(char) != 1, I'm not taking any chances :) > * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. check_signals already bails out if that is the case. But in fact it bails out without setting the interrupt_occurred output parameter, so I fixed that. fcntl error checking... will work on it. ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2006-09-26 17:53 Message: Logged In: YES user_id=12364 I've looked over the patch, although I haven't tested it. I have the following suggestions: * Needs documentation explaining the signal weirdness (may drop signals, may delay indefinitely, new handlers may get signals intended for old, etc) * Needs to be explicit that users must only poll/select to check for readability of the pipe, NOT read from it * The comment for is_tripped refers to sigcheck(), which doesn't exist * I think we should be more paranoid about the range of possible signals. NSIG does not appear to be defined by SUSv2 (no clue about Posix). We should size the Handlers array to UCHAR_MAX and set any signals outside the range of 0..UCHAR_MAX to either 0 (null signal) or UCHAR_MAX. I'm not sure we should ever use NSIG. * In signal_hander() sizeof(signum_c) is inherently 1. ;) * The set_nonblock macro doesn't check for errors from fcntl(). I'm not sure it's worth having a macro for that anyway. * Needs some documentation of the assumptions about read()/write() being memory barriers. * In check_signals() sizeof(signum) is inherently 1. * There's a blank line with tabs near the end of check_signals() ;) * PyErr_SetInterrupt() should use a compile-time check for SIGINT being within 0..UCHAR_MAX, assuming NSIG is ripped out entierly. * PyErr_SetInterrupt() needs to set is_tripped after the call to write(), not before. * PyOS_InterruptOccurred() should probably still check that it's called from the main thread. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1564547&group_id=5470 From noreply at sourceforge.net Sat Sep 30 10:44:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 01:44:01 -0700 Subject: [Patches] [ python-Patches-1567691 ] super() and instancemethod() shouldn't accept keyword args Message-ID: Patches item #1567691, was opened at 2006-09-29 12:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567691&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: Fixed Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: super() and instancemethod() shouldn't accept keyword args Initial Comment: Constructors for the super() and instancemethod() types currently accept keyword arguments, but don't do anything with them. The patch fixes this by raising a TypeError when they are present. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:44 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 52058, 52059 (2.4), 52060 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567691&group_id=5470 From noreply at sourceforge.net Sat Sep 30 10:45:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 01:45:29 -0700 Subject: [Patches] [ python-Patches-1282340 ] Enable SSL for smtplib Message-ID: Patches item #1282340, was opened at 2005-09-05 16:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1282340&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: Phil Underwood (furbrain) Assigned to: Nobody/Anonymous (nobody) Summary: Enable SSL for smtplib Initial Comment: smtplib already has limited support for using SSL through the starttls function. However, some SMTP servers require an SSL connection right from the start. This patch allows you to use an SMTP_SSL object to connect (in a similar manner to Imap_SSL or POP3_SSL). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:45 Message: Logged In: YES user_id=849994 Superseded by #1567274. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 03:35 Message: Logged In: YES user_id=33168 Thanks for the patch. Can you please provide test and doc updates? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1282340&group_id=5470 From noreply at sourceforge.net Sat Sep 30 10:46:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 01:46:28 -0700 Subject: [Patches] [ python-Patches-1567274 ] Enable SSL for smtplib Message-ID: Patches item #1567274, was opened at 2006-09-28 19:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567274&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: Monty Taylor (sdirector) Assigned to: Nobody/Anonymous (nobody) >Summary: Enable SSL for smtplib Initial Comment: This is related to patch 1282340, which I would like to see merged. Here is the patch again, but this time with changes made to the docs. Please let me know what I can do to move this forward. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:46 Message: Logged In: YES user_id=849994 Thanks! I closed the old patch accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1567274&group_id=5470 From noreply at sourceforge.net Sat Sep 30 10:48:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 01:48:32 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 07:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&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: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 08:48 Message: Logged In: YES user_id=849994 Time to checkin for 2.5.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 19:48 Message: Logged In: YES user_id=33168 Committed revision 51439. (2.6) Thomas Wouters thinks this is fine to go in 2.5. I'll leave open for now until we decide what to do. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-21 19:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 15:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 08:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:07:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:07:06 -0700 Subject: [Patches] [ python-Patches-1560617 ] pyclbr reports different module for Class and Function Message-ID: Patches item #1560617, was opened at 2006-09-18 10:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560617&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: Peter Otten (potten) Assigned to: Nobody/Anonymous (nobody) Summary: pyclbr reports different module for Class and Function Initial Comment: Starting with Python 2.4 pyclbr gives the qualified module name, but only for classes, not functions: >>> import pyclbr >>> for obj in pyclbr.readmodule_ex("test.test_pyclbr").values(): ... print ["func", "class"][isinstance(obj, pyclbr.Class)], obj.name, obj.module ... func test_main test_pyclbr class PyclbrTest test.test_pyclbr The fix is simple, see attached diffs. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:07 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 52069, 52070 (2.4), 52071 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1560617&group_id=5470 From noreply at sourceforge.net Sat Sep 30 13:17:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 04:17:58 -0700 Subject: [Patches] [ python-Patches-1557390 ] datetime's strftime limits strings to 127 chars Message-ID: Patches item #1557390, was opened at 2006-09-12 19:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557390&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: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: datetime's strftime limits strings to 127 chars Initial Comment: See bug http://python.org/sf/1556784 By putting the length into a char, wrap_strftime() restricts the format string to be 127 characters long. This patch removes that restriction, but using Py_ssize_t. Test included. Patch is against release25-maint. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:17 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 52072, 52073 (2.4), 52074 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557390&group_id=5470 From noreply at sourceforge.net Sat Sep 30 21:28:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 12:28:50 -0700 Subject: [Patches] [ python-Patches-1484695 ] tarfile.py fix for #1471427 and updates Message-ID: Patches item #1484695, was opened at 2006-05-09 15:51 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&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: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for #1471427 and updates Initial Comment: I have assembled a patch that adds some features from my own development path of tarfile.py (http://www.gustaebel.de/lars/tarfile/) and fixes #1471427 which made some restructuring necessary. The patch affects Lib/tarfile.py, Lib/test/test_tarfile.py and Doc/lib/libtarfile.tex. The changes the patch makes are as follows: Sets the version to 0.8.0. Support for base256 encoding of number fields (nti() and itn()). Up to now this was hardcoded for the filesize field to allow filesizes greater than 8 GB but it is applicable to all number fields. TarInfo.tobuf() has a boolean argument "posix" which controls how number fields are written (base256 is non-posix). Both unsigned and signed (Sun and NeXT) checksums are calculated. Header validation moves from TarFile.next() to TarInfo.frombuf(). A header is valid only if its checksum is okay, in the past the checksum was calculated but ignored. The TarFile.next() method was rearranged which makes header processing clearer and more abstract and fixes bug #1471427. However, this change breaks the interface for subclassing in order to implement custom member types but makes it much easier at the same time. The mapping TYPE_METH was removed. A new test ReadGNULongTest was added to test_tarfile.py and testtar.tar was updated to be able to test the GNU extensions LONGNAME and LONGLINK. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2006-09-30 21:28 Message: Logged In: YES user_id=100649 Could someone please backport this to 2.4 branch? Currently, 2.4.4c0 is broken when you try to extract a file that happens to have a "/" at index 99 in its name (tarinfo.name ends with "/" in this case, but this is NOT the end of the complete (LONG) filename). It gets misinterpreted as directory in this case. MoinMoin build process is broken on 2.4.4c0 due to this bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 02:23 Message: Logged In: YES user_id=33168 Ah, I see. I checked in the patch to remove the debug message since it's dead code. We are in feature freeze for 2.5, so I've updated the patch, attached it, set the group to 2.6. We can add the patch after 2.5 is out in a month or so. Committed revision 50503. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-09 10:01 Message: Logged In: YES user_id=642936 I attached a tar with two diffs: only-tarfile.diff only removes the debug message. complete-with-headererror.diff removes the debug message and adds the HeaderError exception to TarInfo.frombuf() mentioned below. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 00:04 Message: Logged In: YES user_id=33168 Lars, I don't see the debug (_dbg) call. Which version are you using? I didn't see r46040 in Lib/tafile.py for either 2.5 or 2.4. Could you point me to file/line/version where there's a problem (or just make a patch)? Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-03 10:59 Message: Logged In: YES user_id=642936 I would like to emphasize on point (2) of my previous post, which should be resolved before 2.5 comes out. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-18 12:00 Message: Logged In: YES user_id=642936 On (1): agreed. On (2): There is still a debug message emitted for a bad checksum: In TarInfo.frombuf() at the bottom a ValueError is raised if they don't match and is passed on to TarFile.next() where it is put out as a debug message using the _dbg() method in the except clause. The debug message where it is now (r46040) is senseless because the try-block will be left when TarInfo.frombuf() fails . On (3): You're right, I attached a patch that adds another Exception HeaderError which is raised in TarInfo.frombuf() instead of ValueError in case of a bad header. I hope that is acceptable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-18 08:11 Message: Logged In: YES user_id=849994 Jim: I agree with your comments and have committed an improved version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:25 Message: Logged In: YES user_id=764593 (1) Why change the exception style? When raising an instance, the style guide (PEP-8, http:// www.python.org/dev/peps/pep-0008/) prefers to construct that instance; the older form is left over from String exceptions and will be removed in Python 3. I could understand leaving them as they were, but if you're going to change them to make them consistent, why not use the current format? (2) Why get rid of the debug messages (such as the checksum check) entirely? Guarding them in if self.debug, I would understand. (3) I wouldn't count on str(e) (where e is any ValueError instance) being as meaningful as the (current version's) ReadError("empty, unreadable or compressed file") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-10 18:26 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 45954. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-09 15:52 Message: Logged In: YES user_id=642936 Here is testtar.tar to replace Lib/test/testtar.tar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 From noreply at sourceforge.net Sat Sep 30 21:31:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Sep 2006 12:31:47 -0700 Subject: [Patches] [ python-Patches-1484695 ] tarfile.py fix for #1471427 and updates Message-ID: Patches item #1484695, was opened at 2006-05-09 13:51 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&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: 7 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for #1471427 and updates Initial Comment: I have assembled a patch that adds some features from my own development path of tarfile.py (http://www.gustaebel.de/lars/tarfile/) and fixes #1471427 which made some restructuring necessary. The patch affects Lib/tarfile.py, Lib/test/test_tarfile.py and Doc/lib/libtarfile.tex. The changes the patch makes are as follows: Sets the version to 0.8.0. Support for base256 encoding of number fields (nti() and itn()). Up to now this was hardcoded for the filesize field to allow filesizes greater than 8 GB but it is applicable to all number fields. TarInfo.tobuf() has a boolean argument "posix" which controls how number fields are written (base256 is non-posix). Both unsigned and signed (Sun and NeXT) checksums are calculated. Header validation moves from TarFile.next() to TarInfo.frombuf(). A header is valid only if its checksum is okay, in the past the checksum was calculated but ignored. The TarFile.next() method was rearranged which makes header processing clearer and more abstract and fixes bug #1471427. However, this change breaks the interface for subclassing in order to implement custom member types but makes it much easier at the same time. The mapping TYPE_METH was removed. A new test ReadGNULongTest was added to test_tarfile.py and testtar.tar was updated to be able to test the GNU extensions LONGNAME and LONGLINK. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2006-09-30 19:28 Message: Logged In: YES user_id=100649 Could someone please backport this to 2.4 branch? Currently, 2.4.4c0 is broken when you try to extract a file that happens to have a "/" at index 99 in its name (tarinfo.name ends with "/" in this case, but this is NOT the end of the complete (LONG) filename). It gets misinterpreted as directory in this case. MoinMoin build process is broken on 2.4.4c0 due to this bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 00:23 Message: Logged In: YES user_id=33168 Ah, I see. I checked in the patch to remove the debug message since it's dead code. We are in feature freeze for 2.5, so I've updated the patch, attached it, set the group to 2.6. We can add the patch after 2.5 is out in a month or so. Committed revision 50503. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-09 08:01 Message: Logged In: YES user_id=642936 I attached a tar with two diffs: only-tarfile.diff only removes the debug message. complete-with-headererror.diff removes the debug message and adds the HeaderError exception to TarInfo.frombuf() mentioned below. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-04 22:04 Message: Logged In: YES user_id=33168 Lars, I don't see the debug (_dbg) call. Which version are you using? I didn't see r46040 in Lib/tafile.py for either 2.5 or 2.4. Could you point me to file/line/version where there's a problem (or just make a patch)? Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-03 08:59 Message: Logged In: YES user_id=642936 I would like to emphasize on point (2) of my previous post, which should be resolved before 2.5 comes out. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-18 10:00 Message: Logged In: YES user_id=642936 On (1): agreed. On (2): There is still a debug message emitted for a bad checksum: In TarInfo.frombuf() at the bottom a ValueError is raised if they don't match and is passed on to TarFile.next() where it is put out as a debug message using the _dbg() method in the except clause. The debug message where it is now (r46040) is senseless because the try-block will be left when TarInfo.frombuf() fails . On (3): You're right, I attached a patch that adds another Exception HeaderError which is raised in TarInfo.frombuf() instead of ValueError in case of a bad header. I hope that is acceptable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-18 06:11 Message: Logged In: YES user_id=849994 Jim: I agree with your comments and have committed an improved version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-17 22:25 Message: Logged In: YES user_id=764593 (1) Why change the exception style? When raising an instance, the style guide (PEP-8, http:// www.python.org/dev/peps/pep-0008/) prefers to construct that instance; the older form is left over from String exceptions and will be removed in Python 3. I could understand leaving them as they were, but if you're going to change them to make them consistent, why not use the current format? (2) Why get rid of the debug messages (such as the checksum check) entirely? Guarding them in if self.debug, I would understand. (3) I wouldn't count on str(e) (where e is any ValueError instance) being as meaningful as the (current version's) ReadError("empty, unreadable or compressed file") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-10 16:26 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 45954. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-09 13:52 Message: Logged In: YES user_id=642936 Here is testtar.tar to replace Lib/test/testtar.tar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470