From noreply at sourceforge.net Fri Jun 1 01:00:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 16:00:12 -0700 Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super (PEP 367) Message-ID: Patches item #1727209, was opened at 2007-05-28 22:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: First steps towards new super (PEP 367) Initial Comment: A half-assed start of an implementation for super. This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g. def foo(self, arg, *, super): return super.foo(arg) + 1 Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup. E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C. (I hope to this in a later version.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 19:00 Message: Logged In: YES user_id=6380 Originator: YES This breaks all class methods (as Phillip Eby pointed out): class C: @classmethod def cm(cls): return cls.__name__ class D(C): pass print(D.cm(), D().cm()) This should print "D D" but with the patch it prints "C C". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:45 Message: Logged In: YES user_id=6380 Originator: YES Oops, a last-minute change didn't work out. This version is better. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:24 Message: Logged In: YES user_id=6380 Originator: YES Here's a version that modifies the grammar so 'super' is a keyword. The compiler automatically inserts a 'super' keyword-only argument into a function's signature when the 'super' keyword is used in its body. It works! This requires the p3yk branch at -r55692 or newer. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-29 02:08 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version. Forget about sup.py, the demos are now in Lib/test/test_super.py. Only a few tests fail due to the semantic change (about six files have 1-2 failures each). I think this is acceptable. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:23 Message: Logged In: YES user_id=6380 Originator: YES And a new sup.py example demonstrating that the new patch works. File Added: sup.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:22 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version of the patch where C.f.im_class (in the above example) correctly returns B. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 22:31 Message: Logged In: YES user_id=6380 Originator: YES Here is sup.py, a small demo of how this is supposed to work. File Added: sup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 From noreply at sourceforge.net Fri Jun 1 08:48:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 May 2007 23:48:22 -0700 Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects pprint's handling of 'depth' Message-ID: Patches item #1713041, was opened at 2007-05-04 12:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 Please note that this 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 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1712742: corrects pprint's handling of 'depth' Initial Comment: The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-31 23:48 Message: Logged In: YES user_id=33168 Originator: NO Rodrigo, which patch are you giving +1? Sorry Raghu, I'm getting behind. :-( I'll try to take a look at this. If everything is consistent (docs, code, and tests) and has sane semantics, there shouldn't be anything else necessary. I just need to get the time to apply. Or someone else with commit privileges could apply this as well. If I don't get to this within a week or so, feel free to ping me via mail. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 20:06 Message: Logged In: YES user_id=374783 Originator: NO +1 on the patch (test, code and doc). In particular, if depth == 0 is not allowed, I think the patched behaviour is the expected one, so this is actually a bug fix rather than a change in the module's semantic. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-18 14:16 Message: Logged In: YES user_id=984087 Originator: YES Neal, is there anything else you want me to do for the patch? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 08:09 Message: Logged In: YES user_id=984087 Originator: YES josm, please feel free to go to python-dev if you think community input is required. I personally don't think that it is warranted. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-13 05:14 Message: Logged In: YES user_id=1776568 Originator: NO What is intuitive is a matter of taste. Some people like to count from zero, like many programmers do. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 04:56 Message: Logged In: YES user_id=984087 Originator: YES josm, merely changing (fixing) the handling of "depth" parameter is not a spec change. The patch makes pprint behave in a way that is intuitive from the meaning of "depth". ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-12 07:09 Message: Logged In: YES user_id=1776568 Originator: NO Yes, the doc seems to be wrong, and I agree with you changing wrong doc is always right thing to do, but this patch changed the way how pprint handles 'depth'. I think I can call this as 'a spec change'. changing some existent module's behavior is something that needs to be done carefully. Don't we need a consensus among community? No one cares so much how pprint works? could be ... ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 14:41 Message: Logged In: YES user_id=984087 Originator: YES josm> I just thought if changing the doc itself would cause josm> some problem, we have to fix the code to work the way josm> the doc says. Not if the doc is wrong. josm> Don't we have to get someone's approval to change the josm> spec? We are not changing the spec here. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 14:37 Message: Logged In: YES user_id=1776568 Originator: NO That test case was for pp2.diff. I just thought if changing the doc itself would cause some problem, we have to fix the code to work the way the doc says. Don't we have to get someone's approval to change the spec? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 07:13 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint.patch ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 07:13 Message: Logged In: YES user_id=984087 Originator: YES josm, I don't think there is need for a new test case. The one in the patch correctly tests the code change. As Neal pointed out, the doc is wrong to begin with. I updated the patch with the doc change. Note that I replaced the current example with a very simple one. I believe the current one is overly complicated for this purpose. Comments are welcome, of course. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 04:56 Message: Logged In: YES user_id=1776568 Originator: NO I agree. The code and the doc should be consistent. New test would be Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55223) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,27 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), repr(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), repr(nested_list)) + + result_tuple = {'lv1': '(...)', + 'lv2': '(1, (...))'} + result_dict = {'lv1': '{...}', + 'lv2': '{1: {...}}'} + result_list = {'lv1': '[...]', + 'lv2': '[1, [...]]'} + for i in [1, 2]: + key = 'lv' + `i` + self.assertEqual(pprint.pformat(nested_tuple, depth=i), result_tuple[key]) + self.assertEqual(pprint.pformat(nested_dict, depth=i), result_dict[key]) + self.assertEqual(pprint.pformat(nested_list, depth=i), result_list[key]) + class DottedPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-09 23:18 Message: Logged In: YES user_id=33168 Originator: NO Yes, that's the example I'm referring to. In the doc, it shows 5 numbers and one ... for 6. Without your patch it shows 7 numbers and with your patch it shows 6 numbers. So even with your patch the doc and code don't agree (they are off by one, rather than 2 as is currently the case). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-09 07:44 Message: Logged In: YES user_id=984087 Originator: YES Hi Neal, I assume you are referring to the example >>> import parser >>> tup = parser.ast2tuple( ... parser.suite(open('pprint.py').read()))[1][1][1] >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint(tup) in the document. Is that correct? I ran this example with and without my patch. Without the update, the example printed 7 levels which is one level too deep. With the patch, it printed 6 levels, which seems correct to me. # without patch. prints 7 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (306, (...)))))))) # with patch. prints 6 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (...))))))) I am attaching the file testdoc.py which contains the doc example. I just wanted to confirm that this is what you are referring to. File Added: testdoc.py ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-08 23:56 Message: Logged In: YES user_id=33168 Originator: NO I notice in the doc an example which doesn't work with this patch. It still prints one level too deep. The doc seems correct to me, but I don't have strong feelings any way. The attached patch makes the doc example work as expected. The doc should really be updated with an example more like: >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint((1, (2, (3, (4, (5, (6, 7))))))) (1, (2, (3, (4, (5, (...)))))) >>> pp = pprint.PrettyPrinter(depth=1) >>> pp.pprint(1) 1 >>> pp.pprint([1]) [...] The updated patch causes the new tests to fail. Could you update the test/code/doc to all be consistent? File Added: pp2.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-07 07:49 Message: Logged In: YES user_id=984087 Originator: YES josm, thanks for the test case. I incorporated it into the patch. BTW, I changed "str" to "repr" as I think "repr" is closer to what pformat does. File Added: pprint.patch ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-05 02:02 Message: Logged In: YES user_id=1776568 Originator: NO Your patch looks good and worked fine. Wouldn't it be nice to add a test case for this problem to test_pprint.py? The following is just draft patch to add the test case. Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55144) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,22 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), str(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), str(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), str(nested_list)) + + lv1_tuple = '(1, (...))' + lv1_dict = '{1: {...}}' + lv1_list = '[1, [...]]' + self.assertEqual(pprint.pformat(nested_tuple, depth=1), lv1_tuple) + self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict) + self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list) + ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 12:15 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint_test.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 From noreply at sourceforge.net Fri Jun 1 09:29:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 00:29:51 -0700 Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles properly when package_dir is ' ' Message-ID: Patches item #1720897, was opened at 2007-05-17 11:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470 Please note that this 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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) >Assigned to: Neal Norwitz (nnorwitz) Summary: fix 1668596: copy datafiles properly when package_dir is ' ' Initial Comment: This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names. I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 00:29 Message: Logged In: YES user_id=33168 Originator: NO Test methods shouldn't have docstrings. They screw up the output when running regrtest in verbose mode. Thanks for the patch! This patch failed when running under regrtest (./python -E -tt ./Lib/test/regrtest.py test_distuils) due to output from the distutils command. I just replaced stdout and everything worked. I modified it a bit (made test method name more descriptive and simplified logic a bit). Let me know if I screwed anything up. This still needs to be backported. I'll do it tomorrow unless someone else gets to it first. Committed revision 55731. (2.6) ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 14:10 Message: Logged In: YES user_id=374783 Originator: NO Looks great! I don't mean to sound picky, but I think the comment should go inside the method definition. PEP8 says "Block comments generally apply to some (or all) code that follows them, and are indented to the same level as that code." But, really, now I'm just fine-tuning, the patch is fine as far as I'm concerned :) ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 13:50 Message: Logged In: YES user_id=984087 Originator: YES errebepe, I added a comment to the test case. I need some more time to analyze your find command but that is not relevant to this patch :-). File Added: buildpy_patch.diff ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 12:42 Message: Logged In: YES user_id=374783 Originator: NO True, I couldn't find many tests with docstrings either (though there are a few: find -name test_\*.py -exec egrep -nHB1 '^\s*"""' {} \; | grep -C1 'def test_' | less). On the other hand, most test names are somewhat descriptive of what they are testing. I think a brief description, either in a docstring or in a regular comment (which are common in existing tests), would be helpful to anyone reading it later. As for the rest, great! Thanks for the patch and for the quick response :) ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 12:01 Message: Logged In: YES user_id=984087 Originator: YES File Added: buildpy_patch.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 12:00 Message: Logged In: YES user_id=984087 Originator: YES errebepe, Thanks for the comments. I incorporated your suggestions about the test case. It will now check explicitly for DistutilsFileError and calls self.fail() if it gets this exception. I removed parens in "if (src_dir)" as well. I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it difficult to follow compared to an explicit "if". As to adding a docstring to the test case, I vaguely remember seeing some comment about not having docstrings in test functions. I also don't find docstrings in any of the test functions (found with a quick look at less test_*.py output). ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 10:58 Message: Logged In: YES user_id=374783 Originator: NO +1 on the fix. I do have a few minor suggestions, however. In the fix itself, the parens in "(src_dir)" are still there. If the fix will only be applied in >= 2.5, you might also use the "plen = len(src_dir)+1 if src_dir else 0" form. As for the test, since you're testing a very specific error scenario (Distribution.run_commands raising DistutilsFileError), I'd suggest catching the exception and using "self.fail", so that testing the unfixed code fails instead of issues an error. Since you expect the error to occur inside run_commands, I'd put the try...except block around the "dist.run_commands()" only, as in: # Auxiliary variable, since you need cleanup and self.fail exits before "finally": error = False try: ....dist.run_commands() except DistutilsFileError: ....error = True finally: ....os.chdir(cwd) if error: ....self.fail("run_commands fails with no package_dir") Gustavo Niemeyer also mentioned you should add a dosctring to the test explaining what exactly it's testing. To sum it up, I recommend commit of this patch regardless of my comments above, but I hope they're taken into consideration :) ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 10:19 Message: Logged In: YES user_id=984087 Originator: YES Thanks for reviewing. As for parens, they don't exist in the current patch. Right? I removed them quite some time back. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2007-05-30 09:31 Message: Logged In: YES user_id=56214 Originator: NO +1 on this approach; recommend commit of this patch (note, however, that the parens in "if (src_dir):" are redundant). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-21 11:24 Message: Logged In: YES user_id=984087 Originator: YES I managed to create a test case (is part of the patch now). I ran it on Linux and Windows XP and in both cases, it properly tests the problem. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-21 11:22 Message: Logged In: YES user_id=984087 Originator: YES File Added: buildpy_patch.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-17 11:25 Message: Logged In: YES user_id=984087 Originator: YES File Added: build_py.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-17 11:17 Message: Logged In: YES user_id=984087 Originator: YES File Added: 1668596_test.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470 From noreply at sourceforge.net Fri Jun 1 16:03:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 07:03:50 -0700 Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects pprint's handling of 'depth' Message-ID: Patches item #1713041, was opened at 2007-05-04 16:13 Message generated for change (Comment added) made by errebepe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 Please note that this 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 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1712742: corrects pprint's handling of 'depth' Initial Comment: The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-06-01 11:03 Message: Logged In: YES user_id=374783 Originator: NO Neal: sorry, I understood pprint.patch was the "current", valid patch, and the object of the most recent discussion. This is the one I was referring to. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 03:48 Message: Logged In: YES user_id=33168 Originator: NO Rodrigo, which patch are you giving +1? Sorry Raghu, I'm getting behind. :-( I'll try to take a look at this. If everything is consistent (docs, code, and tests) and has sane semantics, there shouldn't be anything else necessary. I just need to get the time to apply. Or someone else with commit privileges could apply this as well. If I don't get to this within a week or so, feel free to ping me via mail. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-31 00:06 Message: Logged In: YES user_id=374783 Originator: NO +1 on the patch (test, code and doc). In particular, if depth == 0 is not allowed, I think the patched behaviour is the expected one, so this is actually a bug fix rather than a change in the module's semantic. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-18 18:16 Message: Logged In: YES user_id=984087 Originator: YES Neal, is there anything else you want me to do for the patch? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 12:09 Message: Logged In: YES user_id=984087 Originator: YES josm, please feel free to go to python-dev if you think community input is required. I personally don't think that it is warranted. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-13 09:14 Message: Logged In: YES user_id=1776568 Originator: NO What is intuitive is a matter of taste. Some people like to count from zero, like many programmers do. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 08:56 Message: Logged In: YES user_id=984087 Originator: YES josm, merely changing (fixing) the handling of "depth" parameter is not a spec change. The patch makes pprint behave in a way that is intuitive from the meaning of "depth". ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-12 11:09 Message: Logged In: YES user_id=1776568 Originator: NO Yes, the doc seems to be wrong, and I agree with you changing wrong doc is always right thing to do, but this patch changed the way how pprint handles 'depth'. I think I can call this as 'a spec change'. changing some existent module's behavior is something that needs to be done carefully. Don't we need a consensus among community? No one cares so much how pprint works? could be ... ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 18:41 Message: Logged In: YES user_id=984087 Originator: YES josm> I just thought if changing the doc itself would cause josm> some problem, we have to fix the code to work the way josm> the doc says. Not if the doc is wrong. josm> Don't we have to get someone's approval to change the josm> spec? We are not changing the spec here. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 18:37 Message: Logged In: YES user_id=1776568 Originator: NO That test case was for pp2.diff. I just thought if changing the doc itself would cause some problem, we have to fix the code to work the way the doc says. Don't we have to get someone's approval to change the spec? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 11:13 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint.patch ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 11:13 Message: Logged In: YES user_id=984087 Originator: YES josm, I don't think there is need for a new test case. The one in the patch correctly tests the code change. As Neal pointed out, the doc is wrong to begin with. I updated the patch with the doc change. Note that I replaced the current example with a very simple one. I believe the current one is overly complicated for this purpose. Comments are welcome, of course. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 08:56 Message: Logged In: YES user_id=1776568 Originator: NO I agree. The code and the doc should be consistent. New test would be Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55223) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,27 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), repr(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), repr(nested_list)) + + result_tuple = {'lv1': '(...)', + 'lv2': '(1, (...))'} + result_dict = {'lv1': '{...}', + 'lv2': '{1: {...}}'} + result_list = {'lv1': '[...]', + 'lv2': '[1, [...]]'} + for i in [1, 2]: + key = 'lv' + `i` + self.assertEqual(pprint.pformat(nested_tuple, depth=i), result_tuple[key]) + self.assertEqual(pprint.pformat(nested_dict, depth=i), result_dict[key]) + self.assertEqual(pprint.pformat(nested_list, depth=i), result_list[key]) + class DottedPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-10 03:18 Message: Logged In: YES user_id=33168 Originator: NO Yes, that's the example I'm referring to. In the doc, it shows 5 numbers and one ... for 6. Without your patch it shows 7 numbers and with your patch it shows 6 numbers. So even with your patch the doc and code don't agree (they are off by one, rather than 2 as is currently the case). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-09 11:44 Message: Logged In: YES user_id=984087 Originator: YES Hi Neal, I assume you are referring to the example >>> import parser >>> tup = parser.ast2tuple( ... parser.suite(open('pprint.py').read()))[1][1][1] >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint(tup) in the document. Is that correct? I ran this example with and without my patch. Without the update, the example printed 7 levels which is one level too deep. With the patch, it printed 6 levels, which seems correct to me. # without patch. prints 7 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (306, (...)))))))) # with patch. prints 6 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (...))))))) I am attaching the file testdoc.py which contains the doc example. I just wanted to confirm that this is what you are referring to. File Added: testdoc.py ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-09 03:56 Message: Logged In: YES user_id=33168 Originator: NO I notice in the doc an example which doesn't work with this patch. It still prints one level too deep. The doc seems correct to me, but I don't have strong feelings any way. The attached patch makes the doc example work as expected. The doc should really be updated with an example more like: >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint((1, (2, (3, (4, (5, (6, 7))))))) (1, (2, (3, (4, (5, (...)))))) >>> pp = pprint.PrettyPrinter(depth=1) >>> pp.pprint(1) 1 >>> pp.pprint([1]) [...] The updated patch causes the new tests to fail. Could you update the test/code/doc to all be consistent? File Added: pp2.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-07 11:49 Message: Logged In: YES user_id=984087 Originator: YES josm, thanks for the test case. I incorporated it into the patch. BTW, I changed "str" to "repr" as I think "repr" is closer to what pformat does. File Added: pprint.patch ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-05 06:02 Message: Logged In: YES user_id=1776568 Originator: NO Your patch looks good and worked fine. Wouldn't it be nice to add a test case for this problem to test_pprint.py? The following is just draft patch to add the test case. Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55144) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,22 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), str(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), str(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), str(nested_list)) + + lv1_tuple = '(1, (...))' + lv1_dict = '{1: {...}}' + lv1_list = '[1, [...]]' + self.assertEqual(pprint.pformat(nested_tuple, depth=1), lv1_tuple) + self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict) + self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list) + ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 16:15 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint_test.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 From noreply at sourceforge.net Fri Jun 1 16:37:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 Jun 2007 07:37:21 -0700 Subject: [Patches] [ python-Patches-1183712 ] package_data chops off first char of default package Message-ID: Patches item #1183712, was opened at 2005-04-15 08:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: package_data chops off first char of default package Initial Comment: If the package name is an empty string (ie the default package), all package_data files have the first character chopped off. Attached is a test package pytest.tar.gz where running python2.4 setup.py build_py produces this error: running build_py creating build creating build/lib copying __init__.py -> build/lib error: can't copy 'ATA': doesn't exist or not a regular file Also attached is a fix proposal, though I have tested this only against the test package. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-06-01 10:37 Message: Logged In: YES user_id=984087 Originator: NO I suggest that this patch be closed as the code change suggested here is committed (with patch 1720897). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 11:49 Message: Logged In: YES user_id=984087 Originator: NO Please check patch 1720897 which fixes slightly related problem. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2007-02-23 17:07 Message: Logged In: YES user_id=56214 Originator: NO I concur with Martin: setup() should disallow an empty string as a package, because an empty string is not a valid Python package name. Regarding Jim's comment that the stripping should be smarter, I'd like to point out that package_dirs must only contain platform-independent directory names, and if anything else is included, it will produce an error when the build_py command is initialized, as 'convert_path' is called on the paths in question. Thus, they can never contain absolute paths or end in a trailing /. Thus, the only problem here is that packages is allowed to contain empty strings, which it makes no sense to include. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-31 09:26 Message: Logged In: YES user_id=764593 I think the patch is still missing a case or two. plen represents the length of the path prefix to ignore. Today's code computes this as (len(src_dir) + 1) where the +1 is for the "/" added by os.path.join(). As you found, src_dir won't add anything (including the "/") if src_dir is empty. But it also won't add the "/" if src_dir already ends in "/ ", and it won't even add the src_dir if the path is already absolute. I'm not certain that either of these two cases can occur, but it would be safer to assume they can. My suggestion is that the stripping be smarter -- change """ # Strip directory from globbed filenames filenames = [ file[plen:] for file in self.find_data_files(package, src_dir) ] """ to """ # Strip directory from globbed filenames filenames = [ filetail(name, src_dir) for name in self.find_data_files(package, src_dir) ] """ where filetail is a helper function defined as """ def filetail(name, strip_path): if name.startswith(strip_path): kill=len(strip_path) if name[kill] == "/": kill +=1 name=name[kill:] return name """ with tests """ >>> filetail("asdf/bdededf", "asdf") 'bdededf' >>> filetail("asdf/bdededf", "asdf/") 'bdededf' """ ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2006-05-22 16:13 Message: Logged In: YES user_id=9205 I found it in another Python program (don't remember which though). So I did not think of this as an undocumented feature. I tried it and it worked (except the data file stuff :). The patch should not break any currently working setup.py installation, since src_dir is only empty when using '' (empty string) as package name. Perhaps a cleaner approach would be to forbid an empty package name instead of silently accepting it? I am not sure. At least the documentation should mention that empty package names are not allowed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 04:23 Message: Logged In: YES user_id=21627 Why are you using an empty name as the package name? There is no default package in Python, so this shouldn't work at all. ---------------------------------------------------------------------- Comment By: Herv? Cauwelier (hcauwelier) Date: 2005-10-05 07:03 Message: Logged In: YES user_id=1216236 The patch worked well for me, thanks for it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 From noreply at sourceforge.net Sat Jun 2 10:57:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 01:57:18 -0700 Subject: [Patches] [ python-Patches-1660500 ] Hide iteration variable in list comprehensions Message-ID: Patches item #1660500, was opened at 2007-02-15 11:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1660500&group_id=5470 Please note that this 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: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Nick Coghlan (ncoghlan) Assigned to: Georg Brandl (gbrandl) Summary: Hide iteration variable in list comprehensions Initial Comment: This patch hides the iteration variable in list comprehensions. It adds new tests (modelled on the generator expression tests) and also removes some del statements from the standard library (where code previously cleaned up its own namespace). The changes to symtable.[ch] are more significant than strictly necessary - I found it necessary to spend some time cleaning up the code in order to understand what was needed for the list comprehension changes. Given that the 2.x and 3.0 compilers have already diverged fairly significantly, I don't believe this will make the process of keeping them in sync any more difficult than it is already. Assigning to Georg for initial review (as his set comprehensions patch provided a great deal of inspiration for this one). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-02 08:57 Message: Logged In: YES user_id=849994 Originator: NO The compiler package has been thrown out of Py3k, so there's no reason to leave this open anymore. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-04-15 12:06 Message: Logged In: YES user_id=1038590 Originator: YES test_compiler and test_transformer are failing due to the fact that the compiler package still needs some TLC to catch up with the Grammar changes. test_logging, test_tcl and test_structmembers all fail when run with -R 4:3:. However, these failures don't appear to be due to this change. More importantly, no leaks are reported in the new tests that are part of this update (test_listcomps, test_setcomps). Committed as rev 54835. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-14 17:42 Message: Logged In: YES user_id=6380 Originator: NO OK, I think Nick can check it in himself, right Nick? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-04-14 17:01 Message: Logged In: YES user_id=849994 Originator: NO I applied this and ran regrtest -R. Found no refleaks, and the only tests that failed were compiler and transformer, as expected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-14 14:56 Message: Logged In: YES user_id=6380 Originator: NO Assuming all tests pass in a debug build and you don't see any leaks with "regrtest.py -R 4:3:", just check it in! I've been waiting long enough for this. Speedups are for post 3.0a1. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-04-14 08:40 Message: Logged In: YES user_id=1038590 Originator: YES I've uploaded a new version of the patch that is compatible with the py3k SVN branch as of April 14. The patch still includes the various cleanups I made to the symbol table processing while working out how to make this change (use sets where appropriate, avoid using the same variable name to refer to completely different things, make a couple of syntax error messages more explicit). The slowdown should be fixed at the cost of a single function call - the shorter the sequence being iterated over, the greater the percentage slowdown that will be. The speed of generator expressions should actually be (very) marginally increased as they now skip the SETUP_LOOP/POP_BLOCK steps in the same fashion as list comprehensions always have. File Added: new-comps-updated.diff ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-12 12:17 Message: Logged In: YES user_id=1038590 Originator: YES The patch for 'nonlocal' was applied since Georg & I started working on this. It's going to take me a bit of fiddling to update the patch so that the parser/compiler stage play well with each other (I really should have just believed the patch utility when it reported a conflict trying to patch symtable.c). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 22:56 Message: Logged In: YES user_id=6380 Originator: NO Can't say that slowdown bothers me much, if it's typical. However I think you need to do a svn up in your workspace and regenerate the patch; I get FAILED message from patch on all the generated files and a few others: graminit.[ch], symtable.[ch], Python-ast.c, symbol.py. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-26 10:30 Message: Logged In: YES user_id=849994 Originator: NO Okay, I looked at the patch, and apart from a refleak in one of the compiler methods I couldn't find anything wrong. I then manually applied the rest of my set comprehension patch. The result is attached. Grammar, AST and compilation for comprehensions are now really unified. It passes the tests for listcomps, genexps and setcomps. I couldn't check properly for refleaks since e.g. test_genexps leaks in the branch head, as well as some other tests. I'm currently searching for the offending revision(s)... File Added: new-set-comps.diff ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-02-15 12:13 Message: Logged In: YES user_id=1038590 Originator: YES For reference, the original set comprehensions patch & the py3k list discussion: http://www.python.org/sf/1548388 http://mail.python.org/pipermail/python-3000/2006-December/005188.html Note that the current patch ended up looking a *lot* like the original one (the main difference specific to list comprehensions is that the temporary list is built in the inner scope and then returned rather than being passed in as an argument. Additionally, the code has been unified only for the symtable stage - the AST and compilation stages still use separate code for listcomps and genexps). It turns out that there are some really curly scoping problems that using a nested function deals with automatically (see the new test_listcomps.py in the patch for examples). Having a more efficient mechanism specifically for 'transient' scopes like this is an interesting idea, but it's far from easy (mainly because the variables in the scope still need to be properly visible in scopes it *contains*). Adding set comprehensions on top of this patch should be pretty straightforward. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-02-15 11:53 Message: Logged In: YES user_id=1038590 Originator: YES Speed measurements show a significant speed up over trunk & Python 2.4 for module/class level code: (Python 2.4)$ python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 239 msec per loop (Python 2.x trunk)$ ./python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 193 msec per loop (Python 3000)$ ./python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 176 msec per loop This is almost certainly due to the variables and the list object becoming function locals. There is a slowdown inside a function (but we are still faster than Python 2.4): (Python 2.4)$ python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 259 msec per loop (Python 2.x trunk)$ ./python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 176 msec per loop (Python 3000)$ ./python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 185 msec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1660500&group_id=5470 From noreply at sourceforge.net Sat Jun 2 20:54:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 11:54:07 -0700 Subject: [Patches] [ python-Patches-1720897 ] fix 1668596: copy datafiles properly when package_dir is ' ' Message-ID: Patches item #1720897, was opened at 2007-05-17 11:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470 Please note that this 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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Neal Norwitz (nnorwitz) Summary: fix 1668596: copy datafiles properly when package_dir is ' ' Initial Comment: This patch fixes http://www.python.org/sf/1668596. If package_dir is '', there is no need to remove package_dir part from data file path names. I am also attaching 1668596_test.tar.gz. This has the directory I used to test the patch (both on Linux and Windows XP). I will need some more time to come up with a real test case that can be submitted as patch. I am hoping that if there is some one out there who is familiar with distutils test setup, they may be able to come up with a test case quicker than me. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-02 11:54 Message: Logged In: YES user_id=33168 Originator: NO Committed revision 55747. (2.5) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 00:29 Message: Logged In: YES user_id=33168 Originator: NO Test methods shouldn't have docstrings. They screw up the output when running regrtest in verbose mode. Thanks for the patch! This patch failed when running under regrtest (./python -E -tt ./Lib/test/regrtest.py test_distuils) due to output from the distutils command. I just replaced stdout and everything worked. I modified it a bit (made test method name more descriptive and simplified logic a bit). Let me know if I screwed anything up. This still needs to be backported. I'll do it tomorrow unless someone else gets to it first. Committed revision 55731. (2.6) ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 14:10 Message: Logged In: YES user_id=374783 Originator: NO Looks great! I don't mean to sound picky, but I think the comment should go inside the method definition. PEP8 says "Block comments generally apply to some (or all) code that follows them, and are indented to the same level as that code." But, really, now I'm just fine-tuning, the patch is fine as far as I'm concerned :) ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 13:50 Message: Logged In: YES user_id=984087 Originator: YES errebepe, I added a comment to the test case. I need some more time to analyze your find command but that is not relevant to this patch :-). File Added: buildpy_patch.diff ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 12:42 Message: Logged In: YES user_id=374783 Originator: NO True, I couldn't find many tests with docstrings either (though there are a few: find -name test_\*.py -exec egrep -nHB1 '^\s*"""' {} \; | grep -C1 'def test_' | less). On the other hand, most test names are somewhat descriptive of what they are testing. I think a brief description, either in a docstring or in a regular comment (which are common in existing tests), would be helpful to anyone reading it later. As for the rest, great! Thanks for the patch and for the quick response :) ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 12:01 Message: Logged In: YES user_id=984087 Originator: YES File Added: buildpy_patch.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 12:00 Message: Logged In: YES user_id=984087 Originator: YES errebepe, Thanks for the comments. I incorporated your suggestions about the test case. It will now check explicitly for DistutilsFileError and calls self.fail() if it gets this exception. I removed parens in "if (src_dir)" as well. I considered "plen = len(src_dir)+1 if src_dir else 0" form but I found it difficult to follow compared to an explicit "if". As to adding a docstring to the test case, I vaguely remember seeing some comment about not having docstrings in test functions. I also don't find docstrings in any of the test functions (found with a quick look at less test_*.py output). ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 10:58 Message: Logged In: YES user_id=374783 Originator: NO +1 on the fix. I do have a few minor suggestions, however. In the fix itself, the parens in "(src_dir)" are still there. If the fix will only be applied in >= 2.5, you might also use the "plen = len(src_dir)+1 if src_dir else 0" form. As for the test, since you're testing a very specific error scenario (Distribution.run_commands raising DistutilsFileError), I'd suggest catching the exception and using "self.fail", so that testing the unfixed code fails instead of issues an error. Since you expect the error to occur inside run_commands, I'd put the try...except block around the "dist.run_commands()" only, as in: # Auxiliary variable, since you need cleanup and self.fail exits before "finally": error = False try: ....dist.run_commands() except DistutilsFileError: ....error = True finally: ....os.chdir(cwd) if error: ....self.fail("run_commands fails with no package_dir") Gustavo Niemeyer also mentioned you should add a dosctring to the test explaining what exactly it's testing. To sum it up, I recommend commit of this patch regardless of my comments above, but I hope they're taken into consideration :) ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-30 10:19 Message: Logged In: YES user_id=984087 Originator: YES Thanks for reviewing. As for parens, they don't exist in the current patch. Right? I removed them quite some time back. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2007-05-30 09:31 Message: Logged In: YES user_id=56214 Originator: NO +1 on this approach; recommend commit of this patch (note, however, that the parens in "if (src_dir):" are redundant). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-21 11:24 Message: Logged In: YES user_id=984087 Originator: YES I managed to create a test case (is part of the patch now). I ran it on Linux and Windows XP and in both cases, it properly tests the problem. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-21 11:22 Message: Logged In: YES user_id=984087 Originator: YES File Added: buildpy_patch.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-17 11:25 Message: Logged In: YES user_id=984087 Originator: YES File Added: build_py.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-17 11:17 Message: Logged In: YES user_id=984087 Originator: YES File Added: 1668596_test.tar.gz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720897&group_id=5470 From noreply at sourceforge.net Sat Jun 2 23:35:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 02 Jun 2007 14:35:18 -0700 Subject: [Patches] [ python-Patches-1667860 ] urllib2 raises an UnboundLocalError if "auth-int" is the qop Message-ID: Patches item #1667860, was opened at 2007-02-24 15:19 Message generated for change (Comment added) made by varmaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470 Please note that this 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 Private: No Submitted By: Atul Varma (varmaa) Assigned to: Georg Brandl (gbrandl) Summary: urllib2 raises an UnboundLocalError if "auth-int" is the qop Initial Comment: If a proxy server is connected to that specifies the "auth-int" quality of protection (qop) code--or any qop code aside from "auth", actually--urllib2 raises an UnboundLocalError exception. While this patch doesn't implement auth-int, it does modify the behavior of urllib2 such that it raises a URLError with the reason "qop '%s' is not supported', where %s is the name of the qop code. Two unit tests that test urllib2's functionality with an in-process proxy can be found at: http://varmaa.googlepages.com/Urllib2ProxyTests.py I will try to attach this file to this patch ticket if I can. I am also interested in integrating this unit testing suite with the Python standard lib unit tests, and am willing to work with you if this is desirable. One of the unit tests in this suite succeeds with the standard version of urllib2.py, but the other fails unless this patch is applied. This patch (and the unit test suite) applies to Python 2.4 and 2.5. ---------------------------------------------------------------------- >Comment By: Atul Varma (varmaa) Date: 2007-06-02 21:35 Message: Logged In: YES user_id=863202 Originator: YES Okay, the broken pipe bug should be fixed now--let me know if there are any other problems, or if the broken pipe bug persists. File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-05-11 15:07 Message: Logged In: YES user_id=863202 Originator: YES Ack, sorry about that Georg--I'll investigate and fix this over the weekend. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-11 11:38 Message: Logged In: YES user_id=849994 Originator: NO I get this error with the newest test file: test_urllib2_localnet Traceback (most recent call last): File "/home/gbr/devel/python/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/home/gbr/devel/python/Lib/SocketServer.py", line 241, in process_request self.finish_request(request, client_address) File "/home/gbr/devel/python/Lib/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/gbr/devel/python/Lib/SocketServer.py", line 523, in __init__ self.handle() File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 310, in handle_one_request method() File "/home/gbr/devel/python/Lib/test/test_urllib2_localnet.py", line 220, in do_GET self.wfile.write("Our apologies, but our server is down due to " File "/home/gbr/devel/python/Lib/socket.py", line 263, in write self.flush() File "/home/gbr/devel/python/Lib/socket.py", line 250, in flush self._sock.sendall(buffer) error: (32, 'Broken pipe') test test_urllib2_localnet produced unexpected output: ********************************************************************** *** lines 2-4 of actual output doesn't appear in expected output after line 1: + ---------------------------------------- + Exception happened during processing of request from ('127.0.0.1', 33141) + ---------------------------------------- ********************************************************************** 1 test failed: test_urllib2_localnet ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-04-14 21:27 Message: Logged In: YES user_id=863202 Originator: YES Sorry for the delay; I've added two failure cases to the testing suite--one which supplies bad password information and another that has no password information to supply--so the patch should now be complete. Please let me know if you need anything else. File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:08 Message: Logged In: YES user_id=849994 Originator: NO The new test file looks good, so if you complete the patch I'll apply it. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:42 Message: Logged In: YES user_id=863202 Originator: YES Thanks for the feedback, John--I've applied your suggestions to the testing suite (including renaming the file name) and the patch file. The only thing I haven't done yet is add tests for failure cases, but I wanted to submit the "refactored" version of the test suite before doing that so I know I'm on the right track. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:38 Message: Logged In: YES user_id=863202 Originator: YES File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:33 Message: Logged In: YES user_id=863202 Originator: YES File Added: urllib2_patch.diff ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 17:37 Message: Logged In: YES user_id=261020 Originator: NO This looks useful. It would be nice to test failure cases too (e.g. wrong password, .add_password() not called, ...). I think if this goes into a new file (which might be reasonable), it should be named something like test_urllib2_localnet.py , to allow for adding more loopback tests, which will not always involve proxy handling. I suppose it should NOT depend on the network resource flag (Lib/test/regrtest.py -u network) since it's only localhost. Style (see PEP 8): Don't put whitespace inside brackets -- e.g. bad: fn( arg ) good: fn(arg) Use this_kind_of_name or thiskind if short, not thisKind. Imports and classes etc. don't need comments to label them as such. Probably is useful to label the BaseHTTPServer code though (maybe '# Local proxy test infrastructure'). See e.g. end of Lib/test/test_urllib2net.py for appropriate stdlib test boilerplate. Your patch has inconsistent line endings, BTW. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-24 15:20 Message: Logged In: YES user_id=863202 Originator: YES File Added: Urllib2ProxyTests.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470 From noreply at sourceforge.net Sun Jun 3 15:16:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 06:16:44 -0700 Subject: [Patches] [ python-Patches-1730217 ] IDLE - configDialog layout cleanup Message-ID: Patches item #1730217, was opened at 2007-06-03 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1730217&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE - configDialog layout cleanup Initial Comment: * Added wm_withdraw() at the beginning of __init__, and wm_deiconify() at the end. This causes the dialog to appear only when it's ready. * Used Tk's LabelFrame widget where appropriate. This requires Tk8.4, which has been shipped with CPython since Python2.4. * Minor changes to padding values and labels Some code regarding the indentation config is commented out on purpose - it can be deleted if deemed unnecessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1730217&group_id=5470 From noreply at sourceforge.net Mon Jun 4 01:20:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 03 Jun 2007 16:20:00 -0700 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 16:57 Message generated for change (Comment added) made by hanwen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- >Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-06-04 00:20 Message: Logged In: YES user_id=161998 Originator: YES "1. Specifying --build should not be necessary, as it should default to" correct. "2. what are the implications of AC_CHECK_TOOLS wrt. the current AC_CHECK_PROGS invocations?" AC_CHECK_TOOLS checks for TARGET-PROG, so it uses the proper cross compile tools. "There is a lot of logic to determine the C++ compiler... " Good point. This uses AC_CHECK_TOOLS too now. "3. should we include config.sub? Can we share it easily with the libffi one? Where do I get the most recent version of it?" config.sub comes from autoconf, and if libffi uses it, it should be the same one. It's a bad idea to put generated files in SVN, as is done now; the same holds for the toplevel configure. Standard practice is to include an autogen.sh script that will invoke the correct autoconf/automake/aclocal/acheader/etc. voodoo to generate the scripts. "4. Where does the mapping of system names from -dumpmachine come from? What would need to be done to eliminate this altogether? What about ac_sys_release?" The mapping has to be maintained by someone. It's not very elegant, but then again, there are some arbitrary mappings in configure.in in the native build for ac_sys_release. IMO it would be better to do away with this completely and use the autoconf/config.sub naming exclusively. "5. Isn't there some autoconf way for detecting a C compiler for the build system? It shouldn't default to 'cc'." I'm not aware of any; what do you think the default should be, if not cc? (There is AC_PROG_CC, but that will look for the X-compiler). "6. I don't think the "skipping import check" warning is needed. Just silently don't perform this check." OK. - note that there are several other "skipping import check" messages, for cygwin and Carbon. "7. What is the meaning of CROSS_TARGET? In some place, it is used like sys.platform (so it should take one of the possible values for sys.platform), in configure.in, it is set to ac_sys_system. I think you should just use MACHDEP here." Good point. I changed this. "8. Why is /usr/local/lib excluded when cross-compiling? Please add a comment (likewise for lib64)" /usr/local/lib/ in general contains libraries for the build system, not the target system. Linking them in will either generate bogus linker errors ("wrong architecture binary") or worse create a module which isn't loadable on the target platform, because the library is missing there. I've added a more generic mechanism, which filters include_dirs so they can only start with $CROSS_ROOT. Something similar should really be applied to the linker directories, but I'm not sure which variable to modify. "Otherwise, it looks fine; I haven't been able to test it yet, though." I've added some more information. If you want to get a cross-compile environtment, you could do mkdir gub ; cd gub ; git init ; git pull git://git.sv.gnu.org/lilypond.git gub: make -f lilypond.make PLATFORMS="freebsd-x86" cross-compilers this will leave a cross compiler in gub/target/freebsd-x86/usr/cross/bin File Added: cross-55748.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-07 12:25 Message: Logged In: YES user_id=21627 Originator: NO A few more comments: 1. Specifying --build should not be necessary, as it should default to config.guess, right? If so, we should document that you cross-compile by passing --host. OTOH, I see it is a bug that you cannot just specify --host... 2. what are the implications of AC_CHECK_TOOLS wrt. the current AC_CHECK_PROGS invocations? There is a lot of logic to determine the C++ compiler... 3. should we include config.sub? Can we share it easily with the libffi one? Where do I get the most recent version of it? 4. Where does the mapping of system names from -dumpmachine come from? What would need to be done to eliminate this altogether? What about ac_sys_release? 5. Isn't there some autoconf way for detecting a C compiler for the build system? It shouldn't default to 'cc'. 6. I don't think the "skipping import check" warning is needed. Just silently don't perform this check. 7. What is the meaning of CROSS_TARGET? In some place, it is used like sys.platform (so it should take one of the possible values for sys.platform), in configure.in, it is set to ac_sys_system. I think you should just use MACHDEP here. 8. Why is /usr/local/lib excluded when cross-compiling? Please add a comment (likewise for lib64) Otherwise, it looks fine; I haven't been able to test it yet, though. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-01-08 07:59 Message: Logged In: YES user_id=161998 Originator: YES Regarding --config-cache, yes you're correct. Regarding extending configure.in, it does already say "configure: error: cannot check for file existence when cross compiling" and exit. What more would you like it to do? I could add a check that the --config-cache is given, although that is not strictly necessary (You can also set the variables in the environment.) ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2007-01-07 22:03 Message: Logged In: YES user_id=1417949 Originator: NO config.cache is not generated or used on my Windows installation of MinGW unless --config-cache is also given as argument to configure, and from the autoconf documentation this seems to be the default behaviour. So you might want to amend the instructions to take that into account. Isn't requiring the user to manually create and edit config.cache resulting in unnecessary work and confusion for the them when it can be addressed in configure.in? Given that checking files is an operation which does not work when cross_compiling is set and checking them results in configure exiting because of this, configure.in can check cross_compiling before trying these checks and avoid them allowing configure to complete. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-01-07 02:37 Message: Logged In: YES user_id=161998 Originator: YES "checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling" You need to set up a config.cache file that contains the correct entry for ac_cv_file__dev_ptmx ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-01-07 02:37 Message: Logged In: YES user_id=161998 Originator: YES "checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling" You need to set up a config.cache file that contains the correct entry for ac_cv_file__dev_ptmx ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2007-01-07 01:50 Message: Logged In: YES user_id=1417949 Originator: NO This: AC_CHECK_FILE(/dev/ptmx, AC_DEFINE(HAVE_DEV_PTMX, 1, [Define if we have /dev/ptmx.])) Is being translated into: echo "$as_me:$LINENO: checking for /dev/ptmx" >&5 echo $ECHO_N "checking for /dev/ptmx... $ECHO_C" >&6 if test "${ac_cv_file__dev_ptmx+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else test "$cross_compiling" = yes && { { echo "$as_me:$LINENO: error: cannot check for file existence when cross compiling" >&5 echo "$as_me: error: cannot check for file existence when cross compiling" >&2;} { (exit 1); exit 1; }; } if test -r "/dev/ptmx"; then ac_cv_file__dev_ptmx=yes else ac_cv_file__dev_ptmx=no fi fi Which exits when I do: $ export CC_FOR_BUILD=gcc $ sh configure --host=arm-eabi With an error like: checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling I am using the latest version of msys/mingw with devkitarm to cross compile. Is this supposed to happen? ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-12-09 23:50 Message: Logged In: YES user_id=161998 Originator: YES this is a patch against a SVN checkout of last week. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-12-09 23:48 Message: Logged In: YES user_id=161998 Originator: YES With cross.patch I've been able to build a working freebsd python on linux. Since you had little problems with the X-compile patches, I'm resubmitting those first. I'd like to give our (admittedly: oddball) mingw version another go when the X-compile patches are in python SVN. Regarding your comments: * what would be a better to import the SO setting? the most reliable way to get something out of a makefile into python is VAR=foo export VAR .. os.environ['VAR'] this doesn't introduce any fragility in parsing/expanding/(un)quoting, so it's actually pretty good. Right now, I'm overriding sysconfig wholesale in setup.py with a sysconfig._config_vars.update (os.environ) but I'm not sure that this affects the settings in build_ext.py. A freebsd -> linux compile does not touch that code, so if you dislike it, we can leave it out. * I've documented the .x extension File Added: cross.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 20:12 Message: Logged In: YES user_id=21627 Originator: NO One more note: it would be best if the patches were against the subversion trunk. They won't be included in the 2.5 maintenance branch (as they are a new feature), so they need to be ported to the trunk, anyway. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 20:06 Message: Logged In: YES user_id=21627 Originator: NO I'll add my comments as I go through the patches. cab1e7d1e54d14a8aab52f0c3b3073c93f75d4fc: - why is there now a mingw32msvc2 platform? If the target is mingw (rather than Cygwin), I'd expect that the target is just Win32/Windows, and that all symbolic constants provided be usable across all Win32 Pythons. - why is h2py run for /usr/include/netinet/in.h? Shouldn't it operate on a target header file? - please include any plat-* files that you generate in the patch. - why do you need dl_nt.c in Modules? Please make it use the one from PC (consider updating the comment about calling initall) b52dbbbbc3adece61496b161d8c22599caae2311 - please combine all patches adding support for __MINGW32__ into a single one. Why is anything needed here at all? I thought Python compiles already with mingw32 (on Windows)? - what is the exclusion of freezing for? 059af829d362b10bb5921367c93a56dbb51ef31b - Why are you taking timeval from winsock2.h? It should come from sys/time.h, and does in my copy of Debian mingw32-runtime. 6a742fb15b28564f9a1bc916c76a28dc672a9b2c - Why are these changes needed? It's Windows, and that is already supported. a838b4780998ef98ae4880c3916274d45b661c82 - Why doesn't that already work on Windows+cygwin+mingw32? f452fe4b95085d8c1ba838bf302a6a48df3c1d31 - I think this should target msvcr71.dll, not msvcrt.dll Please also combine the cross-compilation patches into a single one. - there is no need to provide pyconfig.h.in changes; I'll regenerate that, anyway. 9c022e407c366c9f175e9168542ccc76eae9e3f0 - please integrate those into the large AC_CHECK_FUNCS that already exists 540684d696df6057ee2c9c4e13e33fe450605ffa - Why are you stripping -Wl? 64f5018e975419b2d37c39f457c8732def3288df - Try getting SO from the Makefile, not from the environment (I assume this is also meant to support true distutils packages some day). 7a4e50fb1cf5ff3481aaf7515a784621cbbdac6c - again: what is the "mingw" platform? 7d3a45788a0d83608d10e5c0a34f08b426d62e92 - is this really necessary? I suggest to drop it 23a2dd14933a2aee69f7cdc9f838e4b9c26c1eea - don't include bits/time.h; it's not meant for direct inclusion 6689ca9dea07afbe8a77b7787a5c4e1642f803a1 - what's a .x file? ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-25 15:12 Message: Logged In: YES user_id=161998 Originator: YES I've sent the agreement by snailmail. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2006-11-17 19:57 Message: Logged In: YES user_id=1368960 Originator: NO I do not mind either. I've just signed and faxed contrib-form.html. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:33 Message: Logged In: YES user_id=161998 Originator: YES note that not all of the patch needs to go in its current form. In particular, setup.py should be much more clever to look into build-root for finding libs and include files. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:32 Message: Logged In: YES user_id=161998 Originator: YES I don't mind, and I expect Jan won't have a problem either. What's the procedure: do we send the disclaimer first, or do you do the review, or does everything happen in parallel? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 21:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Mon Jun 4 21:41:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 12:41:48 -0700 Subject: [Patches] [ python-Patches-1730959 ] telnetlib: A callback for monitoring the telnet session Message-ID: Patches item #1730959, was opened at 2007-06-04 19: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=1730959&group_id=5470 Please note that this 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 Private: No Submitted By: Samuel Abels (knipknap) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib: A callback for monitoring the telnet session Initial Comment: When automating a telnet session, you often want to know in realtime what is happening on an active connection. Currently, telnetlib provides the following way to monitor the session: --------------- import sys, getpass from telnetlib import Telnet HOST = "localhost" user = raw_input("Enter your remote account: ") password = getpass.getpass() tn = Telnet(HOST) tn.read_until("login: ") tn.write(user + "\n") if password: tn.read_until("Password: ") tn.write(password + "\n") tn.write("ls\n") tn.write("exit\n") print tn.read_all() --------------- In this case, the last line prints what happened on the session. Often times, you want to watch the session in realtime instead, but telnetlib does not provide a way to do this (AFAIK). I would like to see a callback added into libtelnet, letting you hook into the session such that the following code works: --------------- import sys, getpass from telnetlib import Telnet HOST = "localhost" user = raw_input("Enter your remote account: ") password = getpass.getpass() def filter_cb(session, data): sys.stdout.write(data) return data tn = Telnet(HOST) tn.set_data_filter_callback(filter_cb) tn.read_until("login: ") tn.write(user + "\n") if password: tn.read_until("Password: ") tn.write(password + "\n") tn.write("ls\n") tn.write("exit\n") tn.read_until("logout") --------------- The attached patch (against SVN) implements this behavior. By taking the return value to replace the original data the callback can also be used to implement filters. This is nice for adapting the behavior of a remote machine, for example for filtering out unwanted characters. This is my first patch against Python libraries, so apologies if I missed a guideline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1730959&group_id=5470 From noreply at sourceforge.net Mon Jun 4 23:52:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 14:52:05 -0700 Subject: [Patches] [ python-Patches-1731036 ] BufReader, TextReader for PEP 3116 "New I/O" Message-ID: Patches item #1731036, was opened at 2007-06-04 17:52 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=1731036&group_id=5470 Please note that this 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 Private: No Submitted By: Ilguiz Latypov (ilgiz) Assigned to: Nobody/Anonymous (nobody) Summary: BufReader, TextReader for PEP 3116 "New I/O" Initial Comment: Here is a simple implementation of a line-oriented reader deriving from a buffered reader. Unlike the suggested extra derivation of buffered I/O class from a raw I/O class, my BufReader only wraps an "iterable" stream. Besides, I found I had to return an empty string instead of None on EOF because Python2.5's codecs.py assumes the former. Submitting this just in case it is found useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&group_id=5470 From noreply at sourceforge.net Mon Jun 4 23:57:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 14:57:50 -0700 Subject: [Patches] [ python-Patches-1731036 ] BufReader, TextReader for PEP 3116 "New I/O" Message-ID: Patches item #1731036, was opened at 2007-06-04 17:52 Message generated for change (Comment added) made by ilgiz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&group_id=5470 Please note that this 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 Private: No Submitted By: Ilguiz Latypov (ilgiz) Assigned to: Nobody/Anonymous (nobody) Summary: BufReader, TextReader for PEP 3116 "New I/O" Initial Comment: Here is a simple implementation of a line-oriented reader deriving from a buffered reader. Unlike the suggested extra derivation of buffered I/O class from a raw I/O class, my BufReader only wraps an "iterable" stream. Besides, I found I had to return an empty string instead of None on EOF because Python2.5's codecs.py assumes the former. Submitting this just in case it is found useful. ---------------------------------------------------------------------- >Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-04 17:57 Message: Logged In: YES user_id=281701 Originator: YES (I did not take into account the suggested newline and codec parameters, either). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&group_id=5470 From noreply at sourceforge.net Tue Jun 5 00:17:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 15:17:26 -0700 Subject: [Patches] [ python-Patches-1731049 ] Pruning threading.py from asserts Message-ID: Patches item #1731049, was opened at 2007-06-05 00:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Pruning threading.py from asserts Initial Comment: threading.py heavily uses asserts to protect against undefined behavior. That's no good, because asserts are removed when Python is run with the -O option. The suggested fix is to replace all, or almost all, assertions with more robust RuntimeErrors. The whole change is split in two parts. First a patch which adds tests for the new behavior. Then a patch which fixes threading.py and adds the necessary documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 From noreply at sourceforge.net Tue Jun 5 00:19:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 15:19:34 -0700 Subject: [Patches] [ python-Patches-1731049 ] Pruning threading.py from asserts Message-ID: Patches item #1731049, was opened at 2007-06-05 00:17 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Pruning threading.py from asserts Initial Comment: threading.py heavily uses asserts to protect against undefined behavior. That's no good, because asserts are removed when Python is run with the -O option. The suggested fix is to replace all, or almost all, assertions with more robust RuntimeErrors. The whole change is split in two parts. First a patch which adds tests for the new behavior. Then a patch which fixes threading.py and adds the necessary documentation. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 00:19 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 From noreply at sourceforge.net Tue Jun 5 00:56:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 15:56:03 -0700 Subject: [Patches] [ python-Patches-1731049 ] Pruning threading.py from asserts Message-ID: Patches item #1731049, was opened at 2007-06-05 00:17 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Pruning threading.py from asserts Initial Comment: threading.py heavily uses asserts to protect against undefined behavior. That's no good, because asserts are removed when Python is run with the -O option. The suggested fix is to replace all, or almost all, assertions with more robust RuntimeErrors. The whole change is split in two parts. First a patch which adds tests for the new behavior. Then a patch which fixes threading.py and adds the necessary documentation. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 00:56 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 00:19 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:05:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:05:36 -0700 Subject: [Patches] [ python-Patches-1731049 ] Pruning threading.py from asserts Message-ID: Patches item #1731049, was opened at 2007-06-05 00:17 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Pruning threading.py from asserts Initial Comment: threading.py heavily uses asserts to protect against undefined behavior. That's no good, because asserts are removed when Python is run with the -O option. The suggested fix is to replace all, or almost all, assertions with more robust RuntimeErrors. The whole change is split in two parts. First a patch which adds tests for the new behavior. Then a patch which fixes threading.py and adds the necessary documentation. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 01:05 Message: Logged In: YES user_id=51702 Originator: YES File Added: threading.py-use-real-exceptions.py ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 00:56 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 00:19 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:11:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:11:06 -0700 Subject: [Patches] [ python-Patches-1673759 ] '%G' string formatting doesn't catch same errors as '%g' Message-ID: Patches item #1673759, was opened at 2007-03-05 03:45 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this 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 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: '%G' string formatting doesn't catch same errors as '%g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 01:11 Message: Logged In: YES user_id=51702 Originator: NO Shouldn't this be committed now? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-18 04:57 Message: Logged In: YES user_id=6380 Originator: NO Changing the category to 2.5; since the bug appears in 2.5 and 2.6, this should be applied to 2.5 and to the trunk (i.e. 2.6) and then it will automatically be merged into 3.0 when the next merge is done. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 22:50 Message: Logged In: YES user_id=1740099 Originator: NO lgtm ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 19:58 Message: Logged In: YES user_id=411198 Originator: YES Improved summary. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 19:57 Message: Logged In: YES user_id=411198 Originator: YES Thanks for the catch on the line length. I've updated the patch and attached it. File Added: 1673757-1.diff ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 19:01 Message: Logged In: YES user_id=1740099 Originator: NO Your change in Objects/stringobject.c and Objects/unicodeobject.c goes over the 79 character line limit. Otherwise looks ok - compiles, runs, tests look correct and pass. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 12:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Tue Jun 5 01:23:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 16:23:49 -0700 Subject: [Patches] [ python-Patches-1197207 ] Add proxies arg to urllib.urlretrieve Message-ID: Patches item #1197207, was opened at 2005-05-07 14:21 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197207&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Dubery (jdubery) Assigned to: Nobody/Anonymous (nobody) Summary: Add proxies arg to urllib.urlretrieve Initial Comment: Hi, The attached file is a modified version of the standard library's urllib.py (renamed to avoid import confusion on my system). I've done a simple addition of a "proxies" argument to function urlretrieve in a manner that is consistent with the proxies argument to urlopen. cheers, John Dubery ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 01:23 Message: Logged In: YES user_id=51702 Originator: NO Can you please provide a diff of your patch using "svn diff urllib.py" on a Subversion checkout of Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1197207&group_id=5470 From noreply at sourceforge.net Tue Jun 5 03:44:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 18:44:52 -0700 Subject: [Patches] [ python-Patches-1731036 ] BufReader, TextReader for PEP 3116 "New I/O" Message-ID: Patches item #1731036, was opened at 2007-06-04 14:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&group_id=5470 Please note that this 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 Private: No Submitted By: Ilguiz Latypov (ilgiz) >Assigned to: Guido van Rossum (gvanrossum) Summary: BufReader, TextReader for PEP 3116 "New I/O" Initial Comment: Here is a simple implementation of a line-oriented reader deriving from a buffered reader. Unlike the suggested extra derivation of buffered I/O class from a raw I/O class, my BufReader only wraps an "iterable" stream. Besides, I found I had to return an empty string instead of None on EOF because Python2.5's codecs.py assumes the former. Submitting this just in case it is found useful. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-04 18:44 Message: Logged In: YES user_id=33168 Originator: NO Guido, this might be of interest if you are working on new i/o again. I haven't reviewed it. ---------------------------------------------------------------------- Comment By: Ilguiz Latypov (ilgiz) Date: 2007-06-04 14:57 Message: Logged In: YES user_id=281701 Originator: YES (I did not take into account the suggested newline and codec parameters, either). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731036&group_id=5470 From noreply at sourceforge.net Tue Jun 5 07:25:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 Jun 2007 22:25:31 -0700 Subject: [Patches] [ python-Patches-1731169 ] Expect skips by platform Message-ID: Patches item #1731169, was opened at 2007-06-04 22:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731169&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matt Kraai (kraai) Assigned to: Nobody/Anonymous (nobody) Summary: Expect skips by platform Initial Comment: Some tests are expected to be skipped on all but one or two platforms by being included in the lists of tests to be skipped for all but those one or two platforms. This patch removes such tests from those lists and expects to skip them if the platform isn't one of the few where they aren't skipped. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731169&group_id=5470 From noreply at sourceforge.net Tue Jun 5 14:00:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 05:00:31 -0700 Subject: [Patches] [ python-Patches-1731330 ] Missing Py_DECREF in pysqlite_cache_display Message-ID: Patches item #1731330, was opened at 2007-06-05 22: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=1731330&group_id=5470 Please note that this 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 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Py_DECREF in pysqlite_cache_display Initial Comment: In pysqlite_cache_display, if template is NULL, fmt_args is not decrefed before returning from the function. Diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 From noreply at sourceforge.net Tue Jun 5 16:56:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 07:56:42 -0700 Subject: [Patches] [ python-Patches-1706039 ] Added clearerr() to clear EOF state Message-ID: Patches item #1706039, was opened at 2007-04-23 17:21 Message generated for change (Comment added) made by josm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706039&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: jos (josm) Assigned to: Nobody/Anonymous (nobody) Summary: Added clearerr() to clear EOF state Initial Comment: This patch is to fix bug 1523853. Now file.read() works as written in the doc, which says "An empty string is returned when EOF is encountered immediately." Before this fix, An empty string was returned even when the last read() encountered EOF. ---------------------------------------------------------------------- >Comment By: jos (josm) Date: 2007-06-05 14:56 Message: Logged In: YES user_id=1776568 Originator: YES Could someone please review my patch and give me some feedback? ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-03 10:03 Message: Logged In: YES user_id=1776568 Originator: YES The flag checking is revised. I removed feof() so the checking logic become shorter. I didn't factor out that logic because I think the logic is simple enough Added a comment that mentions bug 1523853. File Added: eof2.diff ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-05-01 14:38 Message: Logged In: YES user_id=835142 Originator: NO The latest patch works on Mac OS 10.4 . I would suggest a few cosmetic changes: 1. Put the flag checking logic in a separate function and call it instead of fread. This will eliminate code duplication. 2. "else" is redundant in + if (ferror(stream)) { + clearerr(stream); + PyErr_SetFromErrno(PyExc_IOError); + return 0; + } else if (feof(stream)) { + clearerr(stream); + } The flow will be more obvious if you write + if (ferror(stream)) { + clearerr(stream); + PyErr_SetFromErrno(PyExc_IOError); + return 0; + } + if (feof(stream)) { + clearerr(stream); + } 3. Please mention bug 1523853 in a comment near the test. otherwise, the patch looks fine. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-04-28 17:03 Message: Logged In: YES user_id=1776568 Originator: YES New patch Attached. I believe this one includes all belopolsky's suggestions. Now all dirty jobs are done in Py_UniversalNewlineFread: 1. calls clearerr if ferror or feof 2. set IOErrorr exception and return The caller just checks whether IOError is occurred or not and does appropriate jobs. The attachment also contains unittest for this problem. File Added: eof.diff ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-25 03:14 Message: Logged In: YES user_id=835142 Originator: NO I have just verified that this issue affects readlines and readinto methods on Mac OS X as well. This tells me that rather than patching all the individual methods, maybe Py_UniversalNewlineFread should be fixed instead. I believe that the current situation where a function that looks like Python API reports errors by setting flags on a FILE object instead of settin the an exception is against python's design. I suggest changing Py_UniversalNewlineFgets so that if fread returns 0, it checks whether that was due to EOF or an error and sets an exception in a case of an error and always calls clearerr. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-04-24 17:15 Message: Logged In: YES user_id=1776568 Originator: YES I confirmed that fread can read data from fp in EOF state on Linux. On OS X, freading from fp in EOF state doesn't work, just return 0. I tested this behavior using the following code. ---------------------------- #include #include main(void) { FILE *fp1, *fp2; int n; char buf[128]; fp1 = fopen("spam.txt", "w+"); fputs("foo", fp1); fseek(fp1, 0L, SEEK_END); if (fread(buf, 1, sizeof(buf), fp1) == 0) fprintf(stderr, "first fread failed\n"); fp2 = fopen("spam.txt", "a+"); fputs("bar", fp2); fclose(fp2); if (feof(fp1)) fprintf(stderr, "after appending some text, fp1 is still eof\n"); if (fread(buf, 1, sizeof(buf), fp1) == 0) fprintf(stderr, "second fread failed\n"); printf("buf: %s\n", buf); fclose(fp1); return 0; } ---------------------------- ============= On Linux ============= first fread failed after appending some text, fp1 is still eof buf: bar ============= On OS X ============= first fread failed after appending some text, fp1 is still eof second fread failed buf: Anyway, I think it's safe and preferable to clear EOF indicator in this case. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-24 04:28 Message: Logged In: YES user_id=835142 Originator: NO Hmm. It looks like glibc's fread will attempt reading even if EOF flag is already set. I've reproduced the problem on OS X 10.4.9 and Python 2.6a0 (trunk:54926M). This patch fixes it. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-04-23 23:27 Message: Logged In: YES user_id=1776568 Originator: YES I can easily reproduce this problem on OS X 10.4.9 using Python 2.4.3 and Python 2.5. Here's the code ################# import os, sys filename = "spam" f = open(filename, "w+") f.seek(0, 2) line = f.read() # EOF # Writing the same file using another fd f2 = open(filename, "a+") f2.write("Spam") f2.flush() f2.close() statinfo = os.stat(filename) print "file size: %d" % statinfo.st_size print "position : %d" % f.tell() line = f.read() # read() returns emtpy!! readlines?() works ok print "line : [%s]" % line ################# On my machine, it outputs the following ### file size: 4 position : 0 line : [] ### And just now I found that on ubuntu on the same machine (vmware), it works collect. ### file size: 4 position : 0 line : [Spam] ### My patched version python outputs the same result as above on OS X. We need clearerr() there, too because clearerr()'s job is not only only clearing error indicators but EOF indicators also. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-23 20:22 Message: Logged In: YES user_id=835142 Originator: NO I was not able to reproduce the problem. I tried to read through the end of the file, append to the file from an external process and read again. It worked as expected: more data was read. The proposed patch seems to be redundant: once ferror(f->f_fp) is known to be 0, clearerr will do nothing and in the alternative branch clearerr is already there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1706039&group_id=5470 From noreply at sourceforge.net Tue Jun 5 20:31:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 11:31:21 -0700 Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects pprint's handling of 'depth' Message-ID: Patches item #1713041, was opened at 2007-05-04 15:13 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 Please note that this 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 Private: No Submitted By: Raghuram Devarakonda (draghuram) >Assigned to: Neal Norwitz (nnorwitz) Summary: fix for 1712742: corrects pprint's handling of 'depth' Initial Comment: The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-06-01 10:03 Message: Logged In: YES user_id=374783 Originator: NO Neal: sorry, I understood pprint.patch was the "current", valid patch, and the object of the most recent discussion. This is the one I was referring to. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 02:48 Message: Logged In: YES user_id=33168 Originator: NO Rodrigo, which patch are you giving +1? Sorry Raghu, I'm getting behind. :-( I'll try to take a look at this. If everything is consistent (docs, code, and tests) and has sane semantics, there shouldn't be anything else necessary. I just need to get the time to apply. Or someone else with commit privileges could apply this as well. If I don't get to this within a week or so, feel free to ping me via mail. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 23:06 Message: Logged In: YES user_id=374783 Originator: NO +1 on the patch (test, code and doc). In particular, if depth == 0 is not allowed, I think the patched behaviour is the expected one, so this is actually a bug fix rather than a change in the module's semantic. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-18 17:16 Message: Logged In: YES user_id=984087 Originator: YES Neal, is there anything else you want me to do for the patch? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 11:09 Message: Logged In: YES user_id=984087 Originator: YES josm, please feel free to go to python-dev if you think community input is required. I personally don't think that it is warranted. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-13 08:14 Message: Logged In: YES user_id=1776568 Originator: NO What is intuitive is a matter of taste. Some people like to count from zero, like many programmers do. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 07:56 Message: Logged In: YES user_id=984087 Originator: YES josm, merely changing (fixing) the handling of "depth" parameter is not a spec change. The patch makes pprint behave in a way that is intuitive from the meaning of "depth". ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-12 10:09 Message: Logged In: YES user_id=1776568 Originator: NO Yes, the doc seems to be wrong, and I agree with you changing wrong doc is always right thing to do, but this patch changed the way how pprint handles 'depth'. I think I can call this as 'a spec change'. changing some existent module's behavior is something that needs to be done carefully. Don't we need a consensus among community? No one cares so much how pprint works? could be ... ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 17:41 Message: Logged In: YES user_id=984087 Originator: YES josm> I just thought if changing the doc itself would cause josm> some problem, we have to fix the code to work the way josm> the doc says. Not if the doc is wrong. josm> Don't we have to get someone's approval to change the josm> spec? We are not changing the spec here. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 17:37 Message: Logged In: YES user_id=1776568 Originator: NO That test case was for pp2.diff. I just thought if changing the doc itself would cause some problem, we have to fix the code to work the way the doc says. Don't we have to get someone's approval to change the spec? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 10:13 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint.patch ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 10:13 Message: Logged In: YES user_id=984087 Originator: YES josm, I don't think there is need for a new test case. The one in the patch correctly tests the code change. As Neal pointed out, the doc is wrong to begin with. I updated the patch with the doc change. Note that I replaced the current example with a very simple one. I believe the current one is overly complicated for this purpose. Comments are welcome, of course. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 07:56 Message: Logged In: YES user_id=1776568 Originator: NO I agree. The code and the doc should be consistent. New test would be Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55223) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,27 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), repr(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), repr(nested_list)) + + result_tuple = {'lv1': '(...)', + 'lv2': '(1, (...))'} + result_dict = {'lv1': '{...}', + 'lv2': '{1: {...}}'} + result_list = {'lv1': '[...]', + 'lv2': '[1, [...]]'} + for i in [1, 2]: + key = 'lv' + `i` + self.assertEqual(pprint.pformat(nested_tuple, depth=i), result_tuple[key]) + self.assertEqual(pprint.pformat(nested_dict, depth=i), result_dict[key]) + self.assertEqual(pprint.pformat(nested_list, depth=i), result_list[key]) + class DottedPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-10 02:18 Message: Logged In: YES user_id=33168 Originator: NO Yes, that's the example I'm referring to. In the doc, it shows 5 numbers and one ... for 6. Without your patch it shows 7 numbers and with your patch it shows 6 numbers. So even with your patch the doc and code don't agree (they are off by one, rather than 2 as is currently the case). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-09 10:44 Message: Logged In: YES user_id=984087 Originator: YES Hi Neal, I assume you are referring to the example >>> import parser >>> tup = parser.ast2tuple( ... parser.suite(open('pprint.py').read()))[1][1][1] >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint(tup) in the document. Is that correct? I ran this example with and without my patch. Without the update, the example printed 7 levels which is one level too deep. With the patch, it printed 6 levels, which seems correct to me. # without patch. prints 7 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (306, (...)))))))) # with patch. prints 6 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (...))))))) I am attaching the file testdoc.py which contains the doc example. I just wanted to confirm that this is what you are referring to. File Added: testdoc.py ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-09 02:56 Message: Logged In: YES user_id=33168 Originator: NO I notice in the doc an example which doesn't work with this patch. It still prints one level too deep. The doc seems correct to me, but I don't have strong feelings any way. The attached patch makes the doc example work as expected. The doc should really be updated with an example more like: >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint((1, (2, (3, (4, (5, (6, 7))))))) (1, (2, (3, (4, (5, (...)))))) >>> pp = pprint.PrettyPrinter(depth=1) >>> pp.pprint(1) 1 >>> pp.pprint([1]) [...] The updated patch causes the new tests to fail. Could you update the test/code/doc to all be consistent? File Added: pp2.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-07 10:49 Message: Logged In: YES user_id=984087 Originator: YES josm, thanks for the test case. I incorporated it into the patch. BTW, I changed "str" to "repr" as I think "repr" is closer to what pformat does. File Added: pprint.patch ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-05 05:02 Message: Logged In: YES user_id=1776568 Originator: NO Your patch looks good and worked fine. Wouldn't it be nice to add a test case for this problem to test_pprint.py? The following is just draft patch to add the test case. Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55144) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,22 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), str(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), str(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), str(nested_list)) + + lv1_tuple = '(1, (...))' + lv1_dict = '{1: {...}}' + lv1_list = '[1, [...]]' + self.assertEqual(pprint.pformat(nested_tuple, depth=1), lv1_tuple) + self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict) + self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list) + ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 15:15 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint_test.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 From noreply at sourceforge.net Tue Jun 5 22:14:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 13:14:36 -0700 Subject: [Patches] [ python-Patches-1731659 ] Improve doc for time.strptime Message-ID: Patches item #1731659, was opened at 2007-06-05 22:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731659&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Improve doc for time.strptime Initial Comment: Here is a patch that adds a small example to time.strptime (and adds a paragraph break). I found the function hard to understand, an example would have helped. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731659&group_id=5470 From noreply at sourceforge.net Tue Jun 5 22:44:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 13:44:32 -0700 Subject: [Patches] [ python-Patches-1100942 ] datetime.strptime constructor added Message-ID: Patches item #1100942, was opened at 2005-01-12 15:53 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josh (josh-sf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.strptime constructor added Initial Comment: Alllow creating new datetime objects by parsing date strings. datetime already has strftime, so adding strptime is logical. The new constructor is equivalent to datetime(*(time.strptime(date_string, format)[0:6])). Patch includes documentation and unit test. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 22:44 Message: Logged In: YES user_id=51702 Originator: NO The patch doesn't apply cleanly anymore, although that was easy to fix. With the patch, I also get a few implicit declaration warnings and a few conflicting type errors. Rearranging the order of the functions solve that. Fixing that makes the code compile. The two new methods seem to work correct, although there should be unit tests. ---------------------------------------------------------------------- Comment By: Josh (josh-sf) Date: 2005-02-17 18:15 Message: Logged In: YES user_id=1194964 The first patch has been applied, now just the second needs to be. (strptime2.diff). That adds support for date and time as well as datetime, as per alanvgreen's suggestion. ---------------------------------------------------------------------- Comment By: Josh (josh-sf) Date: 2005-02-02 01:50 Message: Logged In: YES user_id=1194964 Regarding support by datetime.time and datetime.date, if a date component or a time component is specified, respectively, do you think that we should raise an exception? or should we just ignore it? ---------------------------------------------------------------------- Comment By: Alan Green (alanvgreen) Date: 2005-01-25 13:05 Message: Logged In: YES user_id=1174944 This patch will be welcomed by all of that have had to write "datetime(*(time.strptime(date_string, format)[0:6]))". I don't understand the C API well enough to check if reference counts are handled properly, but otherwise the implementation looks straight forward. Documentation looks good and the test passes on my machine. Two suggestions: 1. In the time module, the strptime() function's format parameter is optional. For consistency's sake, I'd expect datetime.strptime()'s format parameter also to be optional. (On the other hand, the default value for the format is not very useful.) 2. Since strftime is supported by datetime.time, datetime.date and datetime.datetime, I'd also expect strptime to be supported by all three classes. Could you add that now, or would it be better to do it as a separate patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1100942&group_id=5470 From noreply at sourceforge.net Tue Jun 5 23:25:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 14:25:22 -0700 Subject: [Patches] [ python-Patches-1731330 ] Missing Py_DECREF in pysqlite_cache_display Message-ID: Patches item #1731330, was opened at 2007-06-05 08:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) >Assigned to: Guido van Rossum (gvanrossum) Summary: Missing Py_DECREF in pysqlite_cache_display Initial Comment: In pysqlite_cache_display, if template is NULL, fmt_args is not decrefed before returning from the function. Diff attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-05 17:25 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 55783. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 From noreply at sourceforge.net Tue Jun 5 23:43:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 14:43:53 -0700 Subject: [Patches] [ python-Patches-1526367 ] str.__iter__ and unicode.__iter__ Message-ID: Patches item #1526367, was opened at 2006-07-21 11:39 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 Please note that this 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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D??rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: str.__iter__ and unicode.__iter__ Initial Comment: This patch add iterator classes for str and unicode, as discussed here: http://mail.python.org/pipermail/python-3000/2006-July/002650.html ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 23:43 Message: Logged In: YES user_id=51702 Originator: NO Patch applies cleanly and works as expected (str.__iter__, unicode.__iter__) and all tests pass. ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2007-03-17 17:55 Message: Logged In: YES user_id=89016 Originator: YES Code coverage is pretty good without any new tests (see ) The only function uncovered is unicodeiter_len (striter_len). I've added a test for this to the new version of the patch (diff2.txt). File Added: diff2.txt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:41 Message: Logged In: YES user_id=849994 Originator: NO This looks good, but needs new tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 From noreply at sourceforge.net Wed Jun 6 00:12:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 15:12:53 -0700 Subject: [Patches] [ python-Patches-1731330 ] Missing Py_DECREF in pysqlite_cache_display Message-ID: Patches item #1731330, was opened at 2007-06-05 12:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Guido van Rossum (gvanrossum) Summary: Missing Py_DECREF in pysqlite_cache_display Initial Comment: In pysqlite_cache_display, if template is NULL, fmt_args is not decrefed before returning from the function. Diff attached. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-05 22:12 Message: Logged In: YES user_id=849994 Originator: NO Backported to 2.5 in rev. 55784. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-05 21:25 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 55783. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 From noreply at sourceforge.net Wed Jun 6 00:21:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 15:21:46 -0700 Subject: [Patches] [ python-Patches-1526367 ] str.__iter__ and unicode.__iter__ Message-ID: Patches item #1526367, was opened at 2006-07-21 04:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 Please note that this 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: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D??rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: str.__iter__ and unicode.__iter__ Initial Comment: This patch add iterator classes for str and unicode, as discussed here: http://mail.python.org/pipermail/python-3000/2006-July/002650.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-05 17:21 Message: Logged In: YES user_id=80475 Originator: NO What is the point of this patch for Py2.6? There is nothing broken here. Not every sequence needs it's own __iter__. That is provided automatically. I intentionally left-out strings from when I added __iter__ to tuples, lists, and dicts. There was no compelling speed benefit as there was for the other objects. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-05 16:43 Message: Logged In: YES user_id=51702 Originator: NO Patch applies cleanly and works as expected (str.__iter__, unicode.__iter__) and all tests pass. ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2007-03-17 11:55 Message: Logged In: YES user_id=89016 Originator: YES Code coverage is pretty good without any new tests (see ) The only function uncovered is unicodeiter_len (striter_len). I've added a test for this to the new version of the patch (diff2.txt). File Added: diff2.txt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 14:41 Message: Logged In: YES user_id=849994 Originator: NO This looks good, but needs new tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 From noreply at sourceforge.net Wed Jun 6 00:24:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 15:24:48 -0700 Subject: [Patches] [ python-Patches-1731720 ] urllib.urlretrieve/URLopener.retrieve - 'buff' argument Message-ID: Patches item #1731720, was opened at 2007-06-05 22:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731720&group_id=5470 Please note that this 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 Private: No Submitted By: Dariusz Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve/URLopener.retrieve - 'buff' argument Initial Comment: Hello, attached is a tiny patch which adds to urllib.urlretrieve and urllib.URLopener.retrieve an optional 'buff' argument, which should be a file-like object (e.g. a StringIO instance). I don't have any performance issues with creating temporary files (right now, anyway..) but it would be nice if I could pass my own objects for those methods to write to. Optionally, it could also raise an exception (ValueError?) if neither 'filename' nor 'buff' were given on input. Diffed against today's trunk. What do you think? Make sense? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731720&group_id=5470 From noreply at sourceforge.net Wed Jun 6 00:25:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 15:25:19 -0700 Subject: [Patches] [ python-Patches-1731720 ] urllib.urlretrieve/URLopener.retrieve - 'buff' argument Message-ID: Patches item #1731720, was opened at 2007-06-05 22:24 Message generated for change (Comment added) made by dsuch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731720&group_id=5470 Please note that this 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 Private: No Submitted By: Dariusz Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve/URLopener.retrieve - 'buff' argument Initial Comment: Hello, attached is a tiny patch which adds to urllib.urlretrieve and urllib.URLopener.retrieve an optional 'buff' argument, which should be a file-like object (e.g. a StringIO instance). I don't have any performance issues with creating temporary files (right now, anyway..) but it would be nice if I could pass my own objects for those methods to write to. Optionally, it could also raise an exception (ValueError?) if neither 'filename' nor 'buff' were given on input. Diffed against today's trunk. What do you think? Make sense? ---------------------------------------------------------------------- >Comment By: Dariusz Suchojad (dsuch) Date: 2007-06-05 22:25 Message: Logged In: YES user_id=954779 Originator: YES Adding a diff. File Added: test_urllib.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731720&group_id=5470 From noreply at sourceforge.net Wed Jun 6 01:25:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 16:25:08 -0700 Subject: [Patches] [ python-Patches-1731330 ] Missing Py_DECREF in pysqlite_cache_display Message-ID: Patches item #1731330, was opened at 2007-06-05 22:00 Message generated for change (Comment added) made by tcdelaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Guido van Rossum (gvanrossum) Summary: Missing Py_DECREF in pysqlite_cache_display Initial Comment: In pysqlite_cache_display, if template is NULL, fmt_args is not decrefed before returning from the function. Diff attached. ---------------------------------------------------------------------- >Comment By: Tim Delaney (tcdelaney) Date: 2007-06-06 09:25 Message: Logged In: YES user_id=603121 Originator: YES This also needs to be applied against the p3yk branch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-06 08:12 Message: Logged In: YES user_id=849994 Originator: NO Backported to 2.5 in rev. 55784. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 07:25 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 55783. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 From noreply at sourceforge.net Wed Jun 6 01:46:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 16:46:44 -0700 Subject: [Patches] [ python-Patches-1731330 ] Missing Py_DECREF in pysqlite_cache_display Message-ID: Patches item #1731330, was opened at 2007-06-05 08:00 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: Tim Delaney (tcdelaney) Assigned to: Guido van Rossum (gvanrossum) Summary: Missing Py_DECREF in pysqlite_cache_display Initial Comment: In pysqlite_cache_display, if template is NULL, fmt_args is not decrefed before returning from the function. Diff attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-05 19:46 Message: Logged In: YES user_id=6380 Originator: NO That will happen in due time the next time we run svnmerge. ---------------------------------------------------------------------- Comment By: Tim Delaney (tcdelaney) Date: 2007-06-05 19:25 Message: Logged In: YES user_id=603121 Originator: YES This also needs to be applied against the p3yk branch. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-05 18:12 Message: Logged In: YES user_id=849994 Originator: NO Backported to 2.5 in rev. 55784. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-05 17:25 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 55783. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731330&group_id=5470 From noreply at sourceforge.net Wed Jun 6 02:17:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 05 Jun 2007 17:17:59 -0700 Subject: [Patches] [ python-Patches-1731049 ] Pruning threading.py from asserts Message-ID: Patches item #1731049, was opened at 2007-06-04 18:17 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Pruning threading.py from asserts Initial Comment: threading.py heavily uses asserts to protect against undefined behavior. That's no good, because asserts are removed when Python is run with the -O option. The suggested fix is to replace all, or almost all, assertions with more robust RuntimeErrors. The whole change is split in two parts. First a patch which adds tests for the new behavior. Then a patch which fixes threading.py and adds the necessary documentation. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-05 20:17 Message: Logged In: YES user_id=1344176 Originator: NO Applied to trunk as r55785. Thanks! ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-04 19:05 Message: Logged In: YES user_id=51702 Originator: YES File Added: threading.py-use-real-exceptions.py ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-04 18:56 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-04 18:19 Message: Logged In: YES user_id=51702 Originator: YES File Added: test_threading-check-for-runtimeerrors.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731049&group_id=5470 From noreply at sourceforge.net Wed Jun 6 10:34:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 01:34:54 -0700 Subject: [Patches] [ python-Patches-1731720 ] urllib.urlretrieve/URLopener.retrieve - 'buff' argument Message-ID: Patches item #1731720, was opened at 2007-06-05 22:24 Message generated for change (Comment added) made by dsuch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731720&group_id=5470 Please note that this 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 Private: No Submitted By: Dariusz Suchojad (dsuch) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve/URLopener.retrieve - 'buff' argument Initial Comment: Hello, attached is a tiny patch which adds to urllib.urlretrieve and urllib.URLopener.retrieve an optional 'buff' argument, which should be a file-like object (e.g. a StringIO instance). I don't have any performance issues with creating temporary files (right now, anyway..) but it would be nice if I could pass my own objects for those methods to write to. Optionally, it could also raise an exception (ValueError?) if neither 'filename' nor 'buff' were given on input. Diffed against today's trunk. What do you think? Make sense? ---------------------------------------------------------------------- >Comment By: Dariusz Suchojad (dsuch) Date: 2007-06-06 08:34 Message: Logged In: YES user_id=954779 Originator: YES Uh, of course I meant the other way around - it could raise an exception if both 'filename' and 'buff' were given on input. ---------------------------------------------------------------------- Comment By: Dariusz Suchojad (dsuch) Date: 2007-06-05 22:25 Message: Logged In: YES user_id=954779 Originator: YES Adding a diff. File Added: test_urllib.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731720&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:03:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:03:42 -0700 Subject: [Patches] [ python-Patches-1520904 ] Fix tests that assume they can write to Lib/test Message-ID: Patches item #1520904, was opened at 2006-07-12 02:53 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: Fix tests that assume they can write to Lib/test Initial Comment: A number of bsddb tests, as well as test_tarfile, create temporary files in Lib/ or {prefix}/lib/pythonX.Y/ . This change uses tempfile.gettempdir() instead. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-06 18:03 Message: Logged In: YES user_id=51702 Originator: NO I think the submitter is referring to the ./Lib/test/testtar.tar file, which one could guess is created when you run test_tarfile.py. But that file is distributed with Python and AFAICT, test_tarfile.py doesn't create temporary files in bad directories. So I think it is safe to close this patch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 16:52 Message: Logged In: YES user_id=11375 Originator: NO Committed the Lib/bsddb changes to the trunk in rev. 53264; thanks! That leaves only the tarfile change to commit, but I'd like to understand why it's necessary first. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 16:14 Message: Logged In: YES user_id=11375 Originator: NO Can you clarify in what cases test_tarfile writes to the current directory? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-31 13:07 Message: Logged In: YES user_id=1126061 This looks fine to me, and a worthwhile change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:13:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:13:40 -0700 Subject: [Patches] [ python-Patches-1666625 ] Allow specifying headers for MIME parts Message-ID: Patches item #1666625, was opened at 2007-02-23 01:18 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1666625&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: J?rg Sonnenberger (jsonn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow specifying headers for MIME parts Initial Comment: The patch is needed to allow specification e.g. of content-transfer-encoding. I couldn't find a way with the existing infrastructure to do that. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-06 18:13 Message: Logged In: YES user_id=51702 Originator: NO The MimeWriter module is deprecated since 2.3, so no point in adding new functionality to it, is there? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for contributing! While I can't speak to whether this patch is a good idea, here are some things you need to fix: 1) Your patch introduces incorrect indentation at line 136 and 137 of Lib/MimeWriter.py (run your updated MimeWriter.py with "python -tt"). 2) The patch lacks test cases (add them to Lib/test/test_MimeWriter.py) and documentation (update Doc/lib/libmimewriter.tex). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1666625&group_id=5470 From noreply at sourceforge.net Wed Jun 6 18:52:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 09:52:00 -0700 Subject: [Patches] [ python-Patches-1665292 ] Datetime enhancements Message-ID: Patches item #1665292, was opened at 2007-02-21 15:55 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 Please note that this 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 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Datetime enhancements Initial Comment: I'm proposing some small enhancements to the datetime module: Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method. Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :] The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch. Thx ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-06 18:52 Message: Logged In: YES user_id=51702 Originator: NO Seems like it is safe to close this patch. If you need a timedelta in seconds it isn't that much work to write td.days*86400+td.seconds to convert it to an int. Converting it to a float doesn't seem useful enough. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-04-21 00:19 Message: Logged In: YES user_id=18139 Originator: NO tiran, having timedelta objects comparable with numbers is going a bit too far. You end up with: timedelta(0, 1) == 1 but hash(timedelta(0, 1)) != hash(1) This breaks dictionaries. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-03-23 03:38 Message: Logged In: YES user_id=560817 Originator: YES Here is a new patch. I've updated the documentation and enhanced the compare function to compare with ints, longs and floats. This part of the patch should be complete. I'm going to submit a different patch for the other features later. Shall I start a new tracker entry? File Added: timedelta_intfloat.diff ---------------------------------------------------------------------- Comment By: Johann C. Rocholl (jcrocholl) Date: 2007-03-09 17:33 Message: Logged In: YES user_id=656137 Originator: NO The patch confuses microseconds with milliseconds. The divisor in delta_float should be 1000000.0, not 1000.0. The result of the last test should be 86401.000001, not 86401.001. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-02-21 17:16 Message: Logged In: YES user_id=560817 Originator: YES File Added: timedelta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 From noreply at sourceforge.net Wed Jun 6 20:53:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 11:53:45 -0700 Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super (PEP 367) Message-ID: Patches item #1727209, was opened at 2007-05-28 22:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: First steps towards new super (PEP 367) Initial Comment: A half-assed start of an implementation for super. This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g. def foo(self, arg, *, super): return super.foo(arg) + 1 Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup. E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C. (I hope to this in a later version.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 14:53 Message: Logged In: YES user_id=6380 Originator: YES I'm starting a new series of patches, super2.diff. These use a completely different tack, inserting a cell variable __class__ into the class shared by all the methods and initialized to the class after it's constructed. Right now, this allows us to write super(__class__, self).method() -- I want to evolve it so that eventually you can write super.method() and super will do the lookup of __class__ and the first argument itself. There's one failing test, testFreeVarInMethod in test_scope.py. This seems significant but I want to upload a checkpoint first. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 19:00 Message: Logged In: YES user_id=6380 Originator: YES This breaks all class methods (as Phillip Eby pointed out): class C: @classmethod def cm(cls): return cls.__name__ class D(C): pass print(D.cm(), D().cm()) This should print "D D" but with the patch it prints "C C". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:45 Message: Logged In: YES user_id=6380 Originator: YES Oops, a last-minute change didn't work out. This version is better. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:24 Message: Logged In: YES user_id=6380 Originator: YES Here's a version that modifies the grammar so 'super' is a keyword. The compiler automatically inserts a 'super' keyword-only argument into a function's signature when the 'super' keyword is used in its body. It works! This requires the p3yk branch at -r55692 or newer. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-29 02:08 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version. Forget about sup.py, the demos are now in Lib/test/test_super.py. Only a few tests fail due to the semantic change (about six files have 1-2 failures each). I think this is acceptable. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:23 Message: Logged In: YES user_id=6380 Originator: YES And a new sup.py example demonstrating that the new patch works. File Added: sup.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:22 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version of the patch where C.f.im_class (in the above example) correctly returns B. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 22:31 Message: Logged In: YES user_id=6380 Originator: YES Here is sup.py, a small demo of how this is supposed to work. File Added: sup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 From noreply at sourceforge.net Wed Jun 6 22:01:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 13:01:10 -0700 Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super (PEP 367) Message-ID: Patches item #1727209, was opened at 2007-05-28 22:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: First steps towards new super (PEP 367) Initial Comment: A half-assed start of an implementation for super. This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g. def foo(self, arg, *, super): return super.foo(arg) + 1 Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup. E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C. (I hope to this in a later version.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:01 Message: Logged In: YES user_id=6380 Originator: YES Here's a better version that lets you use super() as a shorthand for super(__class__, ). test_scope.py still fails though. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 14:53 Message: Logged In: YES user_id=6380 Originator: YES I'm starting a new series of patches, super2.diff. These use a completely different tack, inserting a cell variable __class__ into the class shared by all the methods and initialized to the class after it's constructed. Right now, this allows us to write super(__class__, self).method() -- I want to evolve it so that eventually you can write super.method() and super will do the lookup of __class__ and the first argument itself. There's one failing test, testFreeVarInMethod in test_scope.py. This seems significant but I want to upload a checkpoint first. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 19:00 Message: Logged In: YES user_id=6380 Originator: YES This breaks all class methods (as Phillip Eby pointed out): class C: @classmethod def cm(cls): return cls.__name__ class D(C): pass print(D.cm(), D().cm()) This should print "D D" but with the patch it prints "C C". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:45 Message: Logged In: YES user_id=6380 Originator: YES Oops, a last-minute change didn't work out. This version is better. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:24 Message: Logged In: YES user_id=6380 Originator: YES Here's a version that modifies the grammar so 'super' is a keyword. The compiler automatically inserts a 'super' keyword-only argument into a function's signature when the 'super' keyword is used in its body. It works! This requires the p3yk branch at -r55692 or newer. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-29 02:08 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version. Forget about sup.py, the demos are now in Lib/test/test_super.py. Only a few tests fail due to the semantic change (about six files have 1-2 failures each). I think this is acceptable. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:23 Message: Logged In: YES user_id=6380 Originator: YES And a new sup.py example demonstrating that the new patch works. File Added: sup.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:22 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version of the patch where C.f.im_class (in the above example) correctly returns B. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 22:31 Message: Logged In: YES user_id=6380 Originator: YES Here is sup.py, a small demo of how this is supposed to work. File Added: sup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 From noreply at sourceforge.net Wed Jun 6 22:46:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 13:46:18 -0700 Subject: [Patches] [ python-Patches-1732367 ] Document the constants in the socket module Message-ID: Patches item #1732367, was opened at 2007-06-06 22:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Document the constants in the socket module Initial Comment: I wish to add documentation for the constants in the socket module. AF_*, SO_*, MSG_* etc. Some of them are really useful such as SO_KEEPALIVE and MSG_WAITALL. The modules documentation currently just refers the reader to UNIX manual pages, but I think we can do better. This patch is for the AF_* constants. If it is accepted, I'd like to submit patches for the other constants too. Maybe there should be a subsection for all constants? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 From noreply at sourceforge.net Wed Jun 6 22:57:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 13:57:38 -0700 Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super (PEP 367) Message-ID: Patches item #1727209, was opened at 2007-05-28 22:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: First steps towards new super (PEP 367) Initial Comment: A half-assed start of an implementation for super. This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g. def foo(self, arg, *, super): return super.foo(arg) + 1 Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup. E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C. (I hope to this in a later version.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:57 Message: Logged In: YES user_id=6380 Originator: YES OK, here's today's final version (I hope). This fixes test_scope.py (wasn't too hard after all) and updates the docstring for super(). Question to all: is writing super() acceptable? File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:01 Message: Logged In: YES user_id=6380 Originator: YES Here's a better version that lets you use super() as a shorthand for super(__class__, ). test_scope.py still fails though. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 14:53 Message: Logged In: YES user_id=6380 Originator: YES I'm starting a new series of patches, super2.diff. These use a completely different tack, inserting a cell variable __class__ into the class shared by all the methods and initialized to the class after it's constructed. Right now, this allows us to write super(__class__, self).method() -- I want to evolve it so that eventually you can write super.method() and super will do the lookup of __class__ and the first argument itself. There's one failing test, testFreeVarInMethod in test_scope.py. This seems significant but I want to upload a checkpoint first. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 19:00 Message: Logged In: YES user_id=6380 Originator: YES This breaks all class methods (as Phillip Eby pointed out): class C: @classmethod def cm(cls): return cls.__name__ class D(C): pass print(D.cm(), D().cm()) This should print "D D" but with the patch it prints "C C". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:45 Message: Logged In: YES user_id=6380 Originator: YES Oops, a last-minute change didn't work out. This version is better. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:24 Message: Logged In: YES user_id=6380 Originator: YES Here's a version that modifies the grammar so 'super' is a keyword. The compiler automatically inserts a 'super' keyword-only argument into a function's signature when the 'super' keyword is used in its body. It works! This requires the p3yk branch at -r55692 or newer. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-29 02:08 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version. Forget about sup.py, the demos are now in Lib/test/test_super.py. Only a few tests fail due to the semantic change (about six files have 1-2 failures each). I think this is acceptable. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:23 Message: Logged In: YES user_id=6380 Originator: YES And a new sup.py example demonstrating that the new patch works. File Added: sup.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:22 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version of the patch where C.f.im_class (in the above example) correctly returns B. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 22:31 Message: Logged In: YES user_id=6380 Originator: YES Here is sup.py, a small demo of how this is supposed to work. File Added: sup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 From noreply at sourceforge.net Wed Jun 6 23:00:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 14:00:20 -0700 Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super (PEP 367) Message-ID: Patches item #1727209, was opened at 2007-05-28 22:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: First steps towards new super (PEP 367) Initial Comment: A half-assed start of an implementation for super. This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g. def foo(self, arg, *, super): return super.foo(arg) + 1 Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup. E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C. (I hope to this in a later version.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 17:00 Message: Logged In: YES user_id=6380 Originator: YES Sorry, forgot to add test_super.py to the patch. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:57 Message: Logged In: YES user_id=6380 Originator: YES OK, here's today's final version (I hope). This fixes test_scope.py (wasn't too hard after all) and updates the docstring for super(). Question to all: is writing super() acceptable? File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:01 Message: Logged In: YES user_id=6380 Originator: YES Here's a better version that lets you use super() as a shorthand for super(__class__, ). test_scope.py still fails though. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 14:53 Message: Logged In: YES user_id=6380 Originator: YES I'm starting a new series of patches, super2.diff. These use a completely different tack, inserting a cell variable __class__ into the class shared by all the methods and initialized to the class after it's constructed. Right now, this allows us to write super(__class__, self).method() -- I want to evolve it so that eventually you can write super.method() and super will do the lookup of __class__ and the first argument itself. There's one failing test, testFreeVarInMethod in test_scope.py. This seems significant but I want to upload a checkpoint first. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 19:00 Message: Logged In: YES user_id=6380 Originator: YES This breaks all class methods (as Phillip Eby pointed out): class C: @classmethod def cm(cls): return cls.__name__ class D(C): pass print(D.cm(), D().cm()) This should print "D D" but with the patch it prints "C C". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:45 Message: Logged In: YES user_id=6380 Originator: YES Oops, a last-minute change didn't work out. This version is better. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:24 Message: Logged In: YES user_id=6380 Originator: YES Here's a version that modifies the grammar so 'super' is a keyword. The compiler automatically inserts a 'super' keyword-only argument into a function's signature when the 'super' keyword is used in its body. It works! This requires the p3yk branch at -r55692 or newer. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-29 02:08 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version. Forget about sup.py, the demos are now in Lib/test/test_super.py. Only a few tests fail due to the semantic change (about six files have 1-2 failures each). I think this is acceptable. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:23 Message: Logged In: YES user_id=6380 Originator: YES And a new sup.py example demonstrating that the new patch works. File Added: sup.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:22 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version of the patch where C.f.im_class (in the above example) correctly returns B. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 22:31 Message: Logged In: YES user_id=6380 Originator: YES Here is sup.py, a small demo of how this is supposed to work. File Added: sup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 From noreply at sourceforge.net Thu Jun 7 04:24:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 19:24:59 -0700 Subject: [Patches] [ python-Patches-1666625 ] Allow specifying headers for MIME parts Message-ID: Patches item #1666625, was opened at 2007-02-22 16:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1666625&group_id=5470 Please note that this 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 Private: No Submitted By: J?rg Sonnenberger (jsonn) >Assigned to: Neal Norwitz (nnorwitz) Summary: Allow specifying headers for MIME parts Initial Comment: The patch is needed to allow specification e.g. of content-transfer-encoding. I couldn't find a way with the existing infrastructure to do that. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 19:24 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the comment Bjorn. The module has also been removed from py3k. Jorg, you might want to consider using the email package. I'm not sure if the functionality is in there, but if not, that's where the patch should come from. Thanks for your effort. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-06 09:13 Message: Logged In: YES user_id=51702 Originator: NO The MimeWriter module is deprecated since 2.3, so no point in adding new functionality to it, is there? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 09:15 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for contributing! While I can't speak to whether this patch is a good idea, here are some things you need to fix: 1) Your patch introduces incorrect indentation at line 136 and 137 of Lib/MimeWriter.py (run your updated MimeWriter.py with "python -tt"). 2) The patch lacks test cases (add them to Lib/test/test_MimeWriter.py) and documentation (update Doc/lib/libmimewriter.tex). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1666625&group_id=5470 From noreply at sourceforge.net Thu Jun 7 05:03:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 20:03:43 -0700 Subject: [Patches] [ python-Patches-1520904 ] Fix tests that assume they can write to Lib/test Message-ID: Patches item #1520904, was opened at 2006-07-12 00:53 Message generated for change (Comment added) made by dgreiman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: Fix tests that assume they can write to Lib/test Initial Comment: A number of bsddb tests, as well as test_tarfile, create temporary files in Lib/ or {prefix}/lib/pythonX.Y/ . This change uses tempfile.gettempdir() instead. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- >Comment By: Douglas Greiman (dgreiman) Date: 2007-06-07 03:03 Message: Logged In: YES user_id=1553997 Originator: YES test_tarfile.py was independently fixed by rev 54335. Closing as fixed. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-06 16:03 Message: Logged In: YES user_id=51702 Originator: NO I think the submitter is referring to the ./Lib/test/testtar.tar file, which one could guess is created when you run test_tarfile.py. But that file is distributed with Python and AFAICT, test_tarfile.py doesn't create temporary files in bad directories. So I think it is safe to close this patch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 15:52 Message: Logged In: YES user_id=11375 Originator: NO Committed the Lib/bsddb changes to the trunk in rev. 53264; thanks! That leaves only the tarfile change to commit, but I'd like to understand why it's necessary first. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 15:14 Message: Logged In: YES user_id=11375 Originator: NO Can you clarify in what cases test_tarfile writes to the current directory? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-31 11:07 Message: Logged In: YES user_id=1126061 This looks fine to me, and a worthwhile change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 From noreply at sourceforge.net Thu Jun 7 07:24:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 06 Jun 2007 22:24:18 -0700 Subject: [Patches] [ python-Patches-1731706 ] tkinter memory leak problem Message-ID: Patches item #1731706, was opened at 2007-06-05 14:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731706&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Hancock (robhancock) Assigned to: Martin v. L?wis (loewis) Summary: tkinter memory leak problem Initial Comment: We have a Python application which displays a GUI using Tkinter and Pmw. We have seen that over time the memory usage of the app seems to continuously increase and eventually use up all of the system's RAM. I ran the app under Valgrind, and this leak seems to account for most of the memory that it detects as being leaked: ==31141== 2,630,208 (806,400 direct, 1,823,808 indirect) bytes in 21 blocks are definitely lost in loss record 156 of 159 ==31141== at 0x4A05809: malloc (vg_replace_malloc.c:149) ==31141== by 0x368268844A: TclThreadAllocObj (in /usr/lib64/libtcl8.4.so) ==31141== by 0x3682686BA0: Tcl_NewStringObj (in /usr/lib64/libtcl8.4.so) ==31141== by 0x8B3B258: AsObj (_tkinter.c:902) ==31141== by 0x8B3BB1C: Tkapp_CallArgs (_tkinter.c:1149) ==31141== by 0x8B3BD67: Tkapp_CallProc (_tkinter.c:1224) ==31141== by 0x36826786D4: Tcl_ServiceEvent (in /usr/lib64/libtcl8.4.so) ==31141== by 0x3682678A20: Tcl_DoOneEvent (in /usr/lib64/libtcl8.4.so) ==31141== by 0x8B3F55B: Tkapp_MainLoop (_tkinter.c:2532) ==31141== by 0x36900949D9: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x369009405E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690094485: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095904: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x3690095951: PyEval_EvalCode (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B1EA8: (within /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B3357: PyRun_SimpleFileExFlags (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x36900B979C: Py_Main (in /usr/lib64/libpython2.4.so.1.0) ==31141== by 0x368161D8A3: (below main) (in /lib64/libc-2.5.so) Looking at the code in _tkinter.c, I am not sure how the Tkapp_CallDeallocArgs function is supposed to get called in the case where we push the request onto the Tcl interpreter thread in Tkapp_Call. That call is what would presumably release this allocated memory. This is using Python 2.4.3 and tcl/tk 8.4.13. Looking at Python SVN, there does not seem to be any relevant code changes in _tkinter.c in later versions.. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-06 22:24 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report and patch! Can you attach a python program that demonstrates these bugs? I'd like to add tests for these. The memory leak looks pretty straightforward, but I don't know about the other Condition changes. ---------------------------------------------------------------------- Comment By: Robert Hancock (robhancock) Date: 2007-06-06 09:53 Message: Logged In: YES user_id=1809277 Originator: YES Found a couple of issues in _tkinter.c that appear to have been causing this: -When calls were forwarded onto the Tcl interpreter thread, the Tkapp_CallDeallocArgs function was never called to clean up the converted arguments after the call. -Tcl_Condition variables were never finalized after being used. According to the Tcl documentation, if this is not done they are only cleaned up on program exit, resulting in them accumulating during runtime. I'm attaching a patch against Python 2.4.3 to fix this problem. It likely applies to later versions as well. File Added: python-2.4.3-memleak-fix.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1731706&group_id=5470 From noreply at sourceforge.net Thu Jun 7 15:35:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 06:35:05 -0700 Subject: [Patches] [ python-Patches-1667860 ] urllib2 raises an UnboundLocalError if "auth-int" is the qop Message-ID: Patches item #1667860, was opened at 2007-02-24 15:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470 Please note that this 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: 5 Private: No Submitted By: Atul Varma (varmaa) Assigned to: Georg Brandl (gbrandl) Summary: urllib2 raises an UnboundLocalError if "auth-int" is the qop Initial Comment: If a proxy server is connected to that specifies the "auth-int" quality of protection (qop) code--or any qop code aside from "auth", actually--urllib2 raises an UnboundLocalError exception. While this patch doesn't implement auth-int, it does modify the behavior of urllib2 such that it raises a URLError with the reason "qop '%s' is not supported', where %s is the name of the qop code. Two unit tests that test urllib2's functionality with an in-process proxy can be found at: http://varmaa.googlepages.com/Urllib2ProxyTests.py I will try to attach this file to this patch ticket if I can. I am also interested in integrating this unit testing suite with the Python standard lib unit tests, and am willing to work with you if this is desirable. One of the unit tests in this suite succeeds with the standard version of urllib2.py, but the other fails unless this patch is applied. This patch (and the unit test suite) applies to Python 2.4 and 2.5. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:35 Message: Logged In: YES user_id=849994 Originator: NO Okay, accepted as rev. 55805, 55806 (2.5). Thanks for your continuous efforts! ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-06-02 21:35 Message: Logged In: YES user_id=863202 Originator: YES Okay, the broken pipe bug should be fixed now--let me know if there are any other problems, or if the broken pipe bug persists. File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-05-11 15:07 Message: Logged In: YES user_id=863202 Originator: YES Ack, sorry about that Georg--I'll investigate and fix this over the weekend. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-05-11 11:38 Message: Logged In: YES user_id=849994 Originator: NO I get this error with the newest test file: test_urllib2_localnet Traceback (most recent call last): File "/home/gbr/devel/python/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/home/gbr/devel/python/Lib/SocketServer.py", line 241, in process_request self.finish_request(request, client_address) File "/home/gbr/devel/python/Lib/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/gbr/devel/python/Lib/SocketServer.py", line 523, in __init__ self.handle() File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/gbr/devel/python/Lib/BaseHTTPServer.py", line 310, in handle_one_request method() File "/home/gbr/devel/python/Lib/test/test_urllib2_localnet.py", line 220, in do_GET self.wfile.write("Our apologies, but our server is down due to " File "/home/gbr/devel/python/Lib/socket.py", line 263, in write self.flush() File "/home/gbr/devel/python/Lib/socket.py", line 250, in flush self._sock.sendall(buffer) error: (32, 'Broken pipe') test test_urllib2_localnet produced unexpected output: ********************************************************************** *** lines 2-4 of actual output doesn't appear in expected output after line 1: + ---------------------------------------- + Exception happened during processing of request from ('127.0.0.1', 33141) + ---------------------------------------- ********************************************************************** 1 test failed: test_urllib2_localnet ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-04-14 21:27 Message: Logged In: YES user_id=863202 Originator: YES Sorry for the delay; I've added two failure cases to the testing suite--one which supplies bad password information and another that has no password information to supply--so the patch should now be complete. Please let me know if you need anything else. File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:08 Message: Logged In: YES user_id=849994 Originator: NO The new test file looks good, so if you complete the patch I'll apply it. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:42 Message: Logged In: YES user_id=863202 Originator: YES Thanks for the feedback, John--I've applied your suggestions to the testing suite (including renaming the file name) and the patch file. The only thing I haven't done yet is add tests for failure cases, but I wanted to submit the "refactored" version of the test suite before doing that so I know I'm on the right track. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:38 Message: Logged In: YES user_id=863202 Originator: YES File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:33 Message: Logged In: YES user_id=863202 Originator: YES File Added: urllib2_patch.diff ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 17:37 Message: Logged In: YES user_id=261020 Originator: NO This looks useful. It would be nice to test failure cases too (e.g. wrong password, .add_password() not called, ...). I think if this goes into a new file (which might be reasonable), it should be named something like test_urllib2_localnet.py , to allow for adding more loopback tests, which will not always involve proxy handling. I suppose it should NOT depend on the network resource flag (Lib/test/regrtest.py -u network) since it's only localhost. Style (see PEP 8): Don't put whitespace inside brackets -- e.g. bad: fn( arg ) good: fn(arg) Use this_kind_of_name or thiskind if short, not thisKind. Imports and classes etc. don't need comments to label them as such. Probably is useful to label the BaseHTTPServer code though (maybe '# Local proxy test infrastructure'). See e.g. end of Lib/test/test_urllib2net.py for appropriate stdlib test boilerplate. Your patch has inconsistent line endings, BTW. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-24 15:20 Message: Logged In: YES user_id=863202 Originator: YES File Added: Urllib2ProxyTests.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470 From noreply at sourceforge.net Thu Jun 7 15:44:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 06:44:57 -0700 Subject: [Patches] [ python-Patches-1732367 ] Document the constants in the socket module Message-ID: Patches item #1732367, was opened at 2007-06-06 20:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Document the constants in the socket module Initial Comment: I wish to add documentation for the constants in the socket module. AF_*, SO_*, MSG_* etc. Some of them are really useful such as SO_KEEPALIVE and MSG_WAITALL. The modules documentation currently just refers the reader to UNIX manual pages, but I think we can do better. This patch is for the AF_* constants. If it is accepted, I'd like to submit patches for the other constants too. Maybe there should be a subsection for all constants? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:44 Message: Logged In: YES user_id=849994 Originator: NO I fear that intermixing \dataline with content within one datadesc is not correct. I think I'd put the constants and their explanation into a table. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 From noreply at sourceforge.net Thu Jun 7 19:57:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 10:57:37 -0700 Subject: [Patches] [ python-Patches-1732367 ] Document the constants in the socket module Message-ID: Patches item #1732367, was opened at 2007-06-06 22:46 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Document the constants in the socket module Initial Comment: I wish to add documentation for the constants in the socket module. AF_*, SO_*, MSG_* etc. Some of them are really useful such as SO_KEEPALIVE and MSG_WAITALL. The modules documentation currently just refers the reader to UNIX manual pages, but I think we can do better. This patch is for the AF_* constants. If it is accepted, I'd like to submit patches for the other constants too. Maybe there should be a subsection for all constants? ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-07 19:57 Message: Logged In: YES user_id=51702 Originator: YES I assume you like the general idea of the patch then? I'll create a patch with the tables and create a new subsection to contain them. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 15:44 Message: Logged In: YES user_id=849994 Originator: NO I fear that intermixing \dataline with content within one datadesc is not correct. I think I'd put the constants and their explanation into a table. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 From noreply at sourceforge.net Thu Jun 7 20:05:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 07 Jun 2007 11:05:20 -0700 Subject: [Patches] [ python-Patches-1732367 ] Document the constants in the socket module Message-ID: Patches item #1732367, was opened at 2007-06-06 20:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Document the constants in the socket module Initial Comment: I wish to add documentation for the constants in the socket module. AF_*, SO_*, MSG_* etc. Some of them are really useful such as SO_KEEPALIVE and MSG_WAITALL. The modules documentation currently just refers the reader to UNIX manual pages, but I think we can do better. This patch is for the AF_* constants. If it is accepted, I'd like to submit patches for the other constants too. Maybe there should be a subsection for all constants? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 18:05 Message: Logged In: YES user_id=849994 Originator: NO Yes, more documentation is almost always better than less. :-) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-06-07 17:57 Message: Logged In: YES user_id=51702 Originator: YES I assume you like the general idea of the patch then? I'll create a patch with the tables and create a new subsection to contain them. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-06-07 13:44 Message: Logged In: YES user_id=849994 Originator: NO I fear that intermixing \dataline with content within one datadesc is not correct. I think I'd put the constants and their explanation into a table. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1732367&group_id=5470 From noreply at sourceforge.net Fri Jun 8 20:23:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 11:23:50 -0700 Subject: [Patches] [ python-Patches-1715718 ] x64 clean compile patch for _ctypes Message-ID: Patches item #1715718, was opened at 2007-05-09 15:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1715718&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Kristj?n Valur (krisvale) Assigned to: Thomas Heller (theller) Summary: x64 clean compile patch for _ctypes Initial Comment: A patch to make _ctypes compile cleanly on x64. Mostly it is about changing int to Py_ssize_t where appropriate. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-06-08 20:23 Message: Logged In: YES user_id=11105 Originator: NO I have applied the patch with some small modifications. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1715718&group_id=5470 From noreply at sourceforge.net Fri Jun 8 21:41:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 12:41:11 -0700 Subject: [Patches] [ python-Patches-1703286 ] bug fix: ctypes truncates 64-bit pointers Message-ID: Patches item #1703286, was opened at 2007-04-19 00:09 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703286&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Thomas Heller (theller) Summary: bug fix: ctypes truncates 64-bit pointers Initial Comment: At several places _ctypes module converts a python integer to a void* pointer by first extracting an argument into an int. Attached patch changes int to Py_ssize_t that is guaranteed to be wide enough to hold a pointer. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-06-08 21:41 Message: Logged In: YES user_id=11105 Originator: NO The fix has been backported to the release25-maint branch as SVN rev. 55836. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-04 21:59 Message: Logged In: YES user_id=11105 Originator: NO Fixed in SVN trunk revisions 55129/55131. I will backport the patch to the release25-maint branch later. belopolsky, thanks for your efforts - I hope the changes work for you. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-05-03 21:42 Message: Logged In: YES user_id=11105 Originator: NO IMO the patch is still incorrect. Py_ssize_t cannot be used since sizeof(Py_ssize_t) != sizeof(void *) in older Python versions. Also, the 'n' typecode cannot be used in PyArg_Parse for the same reason. I attach _ctypes-callproc-2.patch, which demonstrates one approach that I think should work. If you can verify that it works I'll apply it. I am not sure it is possible to write really cross-platform test cases. File Added: _ctypes-callproc-2.patch ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-20 23:07 Message: Logged In: YES user_id=835142 Originator: YES I think you meant FreeLibrary function. LoadLibrary seems ok. I am attaching a new patch that should be pre-2.5 compatible and which extends to FreeLibrary. I don't have access to windows, so please check/test that it works. File Added: _ctypes-callproc-1.patch ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-04-20 21:33 Message: Logged In: YES user_id=11105 Originator: NO The patch is only correct for Python2.5 and later, earlier Python versions don't have the Py_ssize_t type (or, when it's defined, it has still the same size as int in these versions). Unfortunately the 'n' typecode also isn't available in these versions. Also the patch has to be extended for Windows, the LoadLibrary function has the same problem. Would you like to extend this patch (for Windows, I can do it myself later)? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-19 08:49 Message: Logged In: YES user_id=33168 Originator: NO Thomas would be the best person to answer you question about where it should go. Maybe he has some other ideas how to test this. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-04-19 08:44 Message: Logged In: YES user_id=835142 Originator: YES Here are (failing) test cases: Python 2.5 (r25:51908, Oct 4 2006, 18:25:28) [GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> dlopen('libc.so.6') 182896775816 >>> dlclose(_) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> dlsym(_, 'printf') Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> call_function(_, ()) # pretend that _ is a function pointer Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum >>> call_cdeclfunction(_, ()) # pretend that _ is a function pointer Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum With the patch: >>> from _ctypes import * >>> dlopen('libc.so.6') 182894214624 >>> dlclose(_) I don't know how to meaningfully exercise call_function and call_cdeclfunction to trigger the bug because in the default (small memory) model on AMD64 function pointers always fit into 32 bits. Maybe a pseudo-function pointer created by an ffi callback can be used for this purpose. I am not sure where these test belong in the testsuit. Maybe in ctypes/test/test_loading.py? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-19 07:56 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the patch. The changes look correct, however, can you create a test for these cases? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703286&group_id=5470 From noreply at sourceforge.net Fri Jun 8 21:42:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 12:42:10 -0700 Subject: [Patches] [ python-Patches-1703300 ] fixes non ansi c declarations in libffi Message-ID: Patches item #1703300, was opened at 2007-04-19 00:29 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703300&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Thomas Heller (theller) Summary: fixes non ansi c declarations in libffi Initial Comment: attached patch fixes compiler warnings Modules/_ctypes/libffi/src/x86/ffi64.c:45: warning: function declaration isn't a prototype Modules/_ctypes/libffi/src/x86/ffi64.c:342: warning: function declaration isn't a prototype from libffi on x86_64 platform. Similar changes should be made for all platforms and submitted upstream (to gcc?). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-06-08 21:42 Message: Logged In: YES user_id=11105 Originator: NO Fixed now in the trunk (for x86 and x64). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-19 07:54 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1703300&group_id=5470 From noreply at sourceforge.net Fri Jun 8 21:48:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 12:48:24 -0700 Subject: [Patches] [ python-Patches-1284670 ] Allow to restrict ModuleFinder to get "direct" dependencies Message-ID: Patches item #1284670, was opened at 2005-09-08 11:28 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284670&group_id=5470 Please note that this 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 Private: No Submitted By: Scherer Michael (misc_from_metz) >Assigned to: Nobody/Anonymous (nobody) Summary: Allow to restrict ModuleFinder to get "direct" dependencies Initial Comment: this patch add a parameter to ModuleFinder, to not recurse when searching module. This way, someone can compute the modules needed by a specific file, without having to compute all other imported module, which may take time for result that are no t needed. With the current system, you cannot create a clean graph of modules dependancy, since they are all on the same level. This patch do not change the default behavior. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-06-08 21:48 Message: Logged In: YES user_id=11105 Originator: NO I have no time or interest in this patch, so unassigning. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 05:39 Message: Logged In: YES user_id=33168 Thomas are you the defacto maintainer of modulefinder? Any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1284670&group_id=5470 From noreply at sourceforge.net Sat Jun 9 08:43:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 08 Jun 2007 23:43:45 -0700 Subject: [Patches] [ python-Patches-1733960 ] Allow T_LONGLONG to accepts ints Message-ID: Patches item #1733960, was opened at 2007-06-09 01: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=1733960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Allow T_LONGLONG to accepts ints Initial Comment: Fix for bug# 1732557 Allows T_LONGLONG and T_ULONGLONG attributes to be set to a plain int ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733960&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:04:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:04:31 -0700 Subject: [Patches] [ python-Patches-1733973 ] _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Message-ID: Patches item #1733973, was opened at 2007-06-09 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733973&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Initial Comment: _lsprof.c:ptrace_enter_call assumes PyErr_* has no errors. It assumes this by feeling free to call functions that PyErr_Clear and overwrite PyErr. This assumption is broken when throwing into a generator. In that case gen_send_ex(.., 1) calls the ptrace_enter_call with an exception already set. This assumption causes two bugs: A. The exception thrown into the generator is overwritten and lost. Later it was also cleared. B. gen_send_ex(..) still returns error-indication, but since the exception was cleared, you get a SystemError (error indication returned but no exception was set). To fix this, ptrace_enter_call now saves/restores the current PyErr. The attached patch was applied on the newest trunk svn. I guess it should be applicable without problems on the 2.5 bugfix branch as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733973&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:07:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:07:00 -0700 Subject: [Patches] [ python-Patches-1733960 ] Allow T_LONGLONG to accepts ints Message-ID: Patches item #1733960, was opened at 2007-06-09 08:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Allow T_LONGLONG to accepts ints Initial Comment: Fix for bug# 1732557 Allows T_LONGLONG and T_ULONGLONG attributes to be set to a plain int ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-09 10:07 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed with r55842, r55843 and r55844 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733960&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:24:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:24:54 -0700 Subject: [Patches] [ python-Patches-1733973 ] _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Message-ID: Patches item #1733973, was opened at 2007-06-09 11:04 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733973&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Initial Comment: _lsprof.c:ptrace_enter_call assumes PyErr_* has no errors. It assumes this by feeling free to call functions that PyErr_Clear and overwrite PyErr. This assumption is broken when throwing into a generator. In that case gen_send_ex(.., 1) calls the ptrace_enter_call with an exception already set. This assumption causes two bugs: A. The exception thrown into the generator is overwritten and lost. Later it was also cleared. B. gen_send_ex(..) still returns error-indication, but since the exception was cleared, you get a SystemError (error indication returned but no exception was set). To fix this, ptrace_enter_call now saves/restores the current PyErr. The attached patch was applied on the newest trunk svn. I guess it should be applicable without problems on the 2.5 bugfix branch as well. ---------------------------------------------------------------------- >Comment By: Eyal Lotem (peaker) Date: 2007-06-09 11:24 Message: Logged In: YES user_id=231480 Originator: YES It seems that bug #1733757 encountered the same bug. See comments on that bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733973&group_id=5470 From noreply at sourceforge.net Sat Jun 9 10:30:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 01:30:34 -0700 Subject: [Patches] [ python-Patches-1733973 ] _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Message-ID: Patches item #1733973, was opened at 2007-06-09 11:04 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733973&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: _lsprof.c:ptrace_enter_call assumes PyErr_* is clean Initial Comment: _lsprof.c:ptrace_enter_call assumes PyErr_* has no errors. It assumes this by feeling free to call functions that PyErr_Clear and overwrite PyErr. This assumption is broken when throwing into a generator. In that case gen_send_ex(.., 1) calls the ptrace_enter_call with an exception already set. This assumption causes two bugs: A. The exception thrown into the generator is overwritten and lost. Later it was also cleared. B. gen_send_ex(..) still returns error-indication, but since the exception was cleared, you get a SystemError (error indication returned but no exception was set). To fix this, ptrace_enter_call now saves/restores the current PyErr. The attached patch was applied on the newest trunk svn. I guess it should be applicable without problems on the 2.5 bugfix branch as well. ---------------------------------------------------------------------- >Comment By: Eyal Lotem (peaker) Date: 2007-06-09 11:30 Message: Logged In: YES user_id=231480 Originator: YES File Added: cProfile.patch ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 11:24 Message: Logged In: YES user_id=231480 Originator: YES It seems that bug #1733757 encountered the same bug. See comments on that bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1733973&group_id=5470 From noreply at sourceforge.net Sat Jun 9 12:54:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 03:54:53 -0700 Subject: [Patches] [ python-Patches-1734014 ] PY_LLONG_MAX and so on Message-ID: Patches item #1734014, was opened at 2007-06-09 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734014&group_id=5470 Please note that this 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 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: PY_LLONG_MAX and so on Initial Comment: Hello. Probably this patch is needed for building python on Windows now. Maybe does LLONG_MAX exist on VC7 or later? Even if so, I think this is better for type __int64. (At least, on VC6 build fails) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734014&group_id=5470 From noreply at sourceforge.net Sun Jun 10 00:45:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 15:45:42 -0700 Subject: [Patches] [ python-Patches-1734234 ] Fast path for unicodedata.normalize() Message-ID: Patches item #1734234, was opened at 2007-06-10 01: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=1734234&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rauli Ruohonen (raulir) Assigned to: Nobody/Anonymous (nobody) Summary: Fast path for unicodedata.normalize() Initial Comment: Implements quick checking of already normalized forms as described in http://unicode.org/reports/tr15/#Annex8 The patch is against 2.6 SVN trunk. Normalization test passes on both UCS2 and UCS4 builds on Ubuntu Edgy. API affected: unicodedata.normalize('NFC', u'a') is u'a' and similar expressions become true, as the unicode object is not copied when it is found to be already normalized. The documentation does not specify either way. Added memory footprint: A new 8-bit field is added to _PyUnicode_DatabaseRecord, and the generated _PyUnicode_Database_Records array grows from 219 records to 304 records. Each record looks like this: typedef struct { const unsigned char category; const unsigned char combining; const unsigned char bidirectional; const unsigned char mirrored; const unsigned char east_asian_width; const unsigned char normalization_quick_check; } _PyUnicode_DatabaseRecord; normalization_quick_check is the added field. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734234&group_id=5470 From noreply at sourceforge.net Sun Jun 10 03:16:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 18:16:43 -0700 Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache optimization updated for Python 2.6 Message-ID: Patches item #1700288, was opened at 2007-04-13 22:16 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Jacobs (bioinformed) Assigned to: Raymond Hettinger (rhettinger) Summary: Armin's method cache optimization updated for Python 2.6 Initial Comment: I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986). I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up. My performance results are not quite as good as Armin's, though still very encouraging. I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%. Given these rather significant results, the major task is to verify correctness. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-10 04:16 Message: Logged In: YES user_id=231480 Originator: NO Why is CPython copying functions to inline them? This is not only code duplication that makes the code easy to break, it also bloats the caller function beyond readability. I believe that using a private .c #include file with an inline keyword, or at worst, #include the function code directly is a better solution. Is there any reason to use the method currently used by CPython? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-05-14 23:18 Message: Logged In: YES user_id=1768698 Originator: YES I tried re-inlining the fast path from _PyType_Lookup() in object.c and found no measurable improvement on the simple benchmarks I tried. I've also stress-tested the patch by disabling the fast-path return, always performing the slow-path lookup, and asserting that the cached result matches the slow-path result. I then ran that modified interpreter on the Python test-suite, various benchmarks, and a range of my own applications. While not a formal proof of correctness, it was encouraging that the cache remained consistent. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-05-14 22:12 Message: Logged In: YES user_id=4771 Originator: NO A further minor improvement could be achieved by re-doing the inlining of _PyType_Lookup() in object.c. Ideally, the fast path only could be inlined, and the rest put in a separate function or just using _PyType_Lookup(). ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-04-14 16:49 Message: Logged In: YES user_id=1768698 Originator: YES I benchmarked using pystone, pybench, and a bunch of my local scientific applications that have tight computational kernels still in pure Python. I tested on a 64bit Linux box, defining the version_tag as either int or unsigned long with no appreciable difference in performance. I'm trying to get parrotbench to run, but it doesn't seem to have been updated for modern Python versions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-14 09:21 Message: Logged In: YES user_id=33168 Originator: NO I tried this test on parrotbench (b0.py in particular) and I'm not sure I could distinguish an improvement over the noise (best case was about 5%). The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc 4.1.2-ish). At first it seemed a bit slower with the original patch which uses unsigned ints. I tried changing to unsigned longs. It seemed a little better, though not sure if it was really due to the change. I think unsigned longs should be used for 64-bit boxes. Did you use a benchmark/program that is open source? I don't know that I have anything decent to test this with. Raymond probably does though. Also what platform did you test on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 From noreply at sourceforge.net Sun Jun 10 04:08:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 19:08:35 -0700 Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache optimization updated for Python 2.6 Message-ID: Patches item #1700288, was opened at 2007-04-13 15:16 Message generated for change (Comment added) made by bioinformed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Jacobs (bioinformed) Assigned to: Raymond Hettinger (rhettinger) Summary: Armin's method cache optimization updated for Python 2.6 Initial Comment: I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986). I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up. My performance results are not quite as good as Armin's, though still very encouraging. I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%. Given these rather significant results, the major task is to verify correctness. ---------------------------------------------------------------------- >Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-09 22:08 Message: Logged In: YES user_id=1768698 Originator: YES First off, all versions of this patch do away with the rather aggressively repeated inline code. My previous comment about refactoring and testing an inlined form were purely an experiment with null results. That aside, you do raise a good question. However, given the current patch, it is unfortunately off-topic and irrelevant to the consideration of this patch. Please feel free to pursue it elsewhere, since I worry that it will only serve as a negative distraction from the much more interesting aims of the mro optimization. Since you are clearly worried about the performance of attribute lookup, please try it out and report your findings. I'll be happy review the results from your benchmarks and any suggestions you have. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 21:16 Message: Logged In: YES user_id=231480 Originator: NO Why is CPython copying functions to inline them? This is not only code duplication that makes the code easy to break, it also bloats the caller function beyond readability. I believe that using a private .c #include file with an inline keyword, or at worst, #include the function code directly is a better solution. Is there any reason to use the method currently used by CPython? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-05-14 16:18 Message: Logged In: YES user_id=1768698 Originator: YES I tried re-inlining the fast path from _PyType_Lookup() in object.c and found no measurable improvement on the simple benchmarks I tried. I've also stress-tested the patch by disabling the fast-path return, always performing the slow-path lookup, and asserting that the cached result matches the slow-path result. I then ran that modified interpreter on the Python test-suite, various benchmarks, and a range of my own applications. While not a formal proof of correctness, it was encouraging that the cache remained consistent. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-05-14 15:12 Message: Logged In: YES user_id=4771 Originator: NO A further minor improvement could be achieved by re-doing the inlining of _PyType_Lookup() in object.c. Ideally, the fast path only could be inlined, and the rest put in a separate function or just using _PyType_Lookup(). ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-04-14 09:49 Message: Logged In: YES user_id=1768698 Originator: YES I benchmarked using pystone, pybench, and a bunch of my local scientific applications that have tight computational kernels still in pure Python. I tested on a 64bit Linux box, defining the version_tag as either int or unsigned long with no appreciable difference in performance. I'm trying to get parrotbench to run, but it doesn't seem to have been updated for modern Python versions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-14 02:21 Message: Logged In: YES user_id=33168 Originator: NO I tried this test on parrotbench (b0.py in particular) and I'm not sure I could distinguish an improvement over the noise (best case was about 5%). The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc 4.1.2-ish). At first it seemed a bit slower with the original patch which uses unsigned ints. I tried changing to unsigned longs. It seemed a little better, though not sure if it was really due to the change. I think unsigned longs should be used for 64-bit boxes. Did you use a benchmark/program that is open source? I don't know that I have anything decent to test this with. Raymond probably does though. Also what platform did you test on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 From noreply at sourceforge.net Sun Jun 10 04:16:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 19:16:16 -0700 Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache optimization updated for Python 2.6 Message-ID: Patches item #1700288, was opened at 2007-04-13 14:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Jacobs (bioinformed) Assigned to: Raymond Hettinger (rhettinger) Summary: Armin's method cache optimization updated for Python 2.6 Initial Comment: I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986). I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up. My performance results are not quite as good as Armin's, though still very encouraging. I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%. Given these rather significant results, the major task is to verify correctness. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-09 21:16 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I'm still reviewing this code. ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-09 21:08 Message: Logged In: YES user_id=1768698 Originator: YES First off, all versions of this patch do away with the rather aggressively repeated inline code. My previous comment about refactoring and testing an inlined form were purely an experiment with null results. That aside, you do raise a good question. However, given the current patch, it is unfortunately off-topic and irrelevant to the consideration of this patch. Please feel free to pursue it elsewhere, since I worry that it will only serve as a negative distraction from the much more interesting aims of the mro optimization. Since you are clearly worried about the performance of attribute lookup, please try it out and report your findings. I'll be happy review the results from your benchmarks and any suggestions you have. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 20:16 Message: Logged In: YES user_id=231480 Originator: NO Why is CPython copying functions to inline them? This is not only code duplication that makes the code easy to break, it also bloats the caller function beyond readability. I believe that using a private .c #include file with an inline keyword, or at worst, #include the function code directly is a better solution. Is there any reason to use the method currently used by CPython? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-05-14 15:18 Message: Logged In: YES user_id=1768698 Originator: YES I tried re-inlining the fast path from _PyType_Lookup() in object.c and found no measurable improvement on the simple benchmarks I tried. I've also stress-tested the patch by disabling the fast-path return, always performing the slow-path lookup, and asserting that the cached result matches the slow-path result. I then ran that modified interpreter on the Python test-suite, various benchmarks, and a range of my own applications. While not a formal proof of correctness, it was encouraging that the cache remained consistent. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-05-14 14:12 Message: Logged In: YES user_id=4771 Originator: NO A further minor improvement could be achieved by re-doing the inlining of _PyType_Lookup() in object.c. Ideally, the fast path only could be inlined, and the rest put in a separate function or just using _PyType_Lookup(). ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-04-14 08:49 Message: Logged In: YES user_id=1768698 Originator: YES I benchmarked using pystone, pybench, and a bunch of my local scientific applications that have tight computational kernels still in pure Python. I tested on a 64bit Linux box, defining the version_tag as either int or unsigned long with no appreciable difference in performance. I'm trying to get parrotbench to run, but it doesn't seem to have been updated for modern Python versions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-14 01:21 Message: Logged In: YES user_id=33168 Originator: NO I tried this test on parrotbench (b0.py in particular) and I'm not sure I could distinguish an improvement over the noise (best case was about 5%). The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc 4.1.2-ish). At first it seemed a bit slower with the original patch which uses unsigned ints. I tried changing to unsigned longs. It seemed a little better, though not sure if it was really due to the change. I think unsigned longs should be used for 64-bit boxes. Did you use a benchmark/program that is open source? I don't know that I have anything decent to test this with. Raymond probably does though. Also what platform did you test on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 From noreply at sourceforge.net Sun Jun 10 04:48:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 19:48:36 -0700 Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache optimization updated for Python 2.6 Message-ID: Patches item #1700288, was opened at 2007-04-13 22:16 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Jacobs (bioinformed) Assigned to: Raymond Hettinger (rhettinger) Summary: Armin's method cache optimization updated for Python 2.6 Initial Comment: I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986). I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up. My performance results are not quite as good as Armin's, though still very encouraging. I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%. Given these rather significant results, the major task is to verify correctness. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-10 05:48 Message: Logged In: YES user_id=231480 Originator: NO I may be missing something trivial here, but why the cache global - and not per-typeobject? As I saw it - the mro cache was supposed to be a mapping of (type,name)->(descriptor/classattr) that's based on the __mro__ of type, and all of the dicts in type and its bases. I think the right way to do it is to use another Pythonic dict object in each type, that holds this cache (name->(descriptor/classattr)). This cache dict should essentially be equivalent to a merge of all the dicts in the mro. and gets updated whenever any of the dicts of the types in the mro gets updated. Not sure why to re-implement a fast-hashtable when one already exists. Also - once it is associated with the type - it does not hold any references to any names that are not already referenced by someone in the type hierarchy, so there are no mm/gc issues either. Am I missing something here? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-10 05:16 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I'm still reviewing this code. ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-10 05:08 Message: Logged In: YES user_id=1768698 Originator: YES First off, all versions of this patch do away with the rather aggressively repeated inline code. My previous comment about refactoring and testing an inlined form were purely an experiment with null results. That aside, you do raise a good question. However, given the current patch, it is unfortunately off-topic and irrelevant to the consideration of this patch. Please feel free to pursue it elsewhere, since I worry that it will only serve as a negative distraction from the much more interesting aims of the mro optimization. Since you are clearly worried about the performance of attribute lookup, please try it out and report your findings. I'll be happy review the results from your benchmarks and any suggestions you have. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-10 04:16 Message: Logged In: YES user_id=231480 Originator: NO Why is CPython copying functions to inline them? This is not only code duplication that makes the code easy to break, it also bloats the caller function beyond readability. I believe that using a private .c #include file with an inline keyword, or at worst, #include the function code directly is a better solution. Is there any reason to use the method currently used by CPython? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-05-14 23:18 Message: Logged In: YES user_id=1768698 Originator: YES I tried re-inlining the fast path from _PyType_Lookup() in object.c and found no measurable improvement on the simple benchmarks I tried. I've also stress-tested the patch by disabling the fast-path return, always performing the slow-path lookup, and asserting that the cached result matches the slow-path result. I then ran that modified interpreter on the Python test-suite, various benchmarks, and a range of my own applications. While not a formal proof of correctness, it was encouraging that the cache remained consistent. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-05-14 22:12 Message: Logged In: YES user_id=4771 Originator: NO A further minor improvement could be achieved by re-doing the inlining of _PyType_Lookup() in object.c. Ideally, the fast path only could be inlined, and the rest put in a separate function or just using _PyType_Lookup(). ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-04-14 16:49 Message: Logged In: YES user_id=1768698 Originator: YES I benchmarked using pystone, pybench, and a bunch of my local scientific applications that have tight computational kernels still in pure Python. I tested on a 64bit Linux box, defining the version_tag as either int or unsigned long with no appreciable difference in performance. I'm trying to get parrotbench to run, but it doesn't seem to have been updated for modern Python versions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-14 09:21 Message: Logged In: YES user_id=33168 Originator: NO I tried this test on parrotbench (b0.py in particular) and I'm not sure I could distinguish an improvement over the noise (best case was about 5%). The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc 4.1.2-ish). At first it seemed a bit slower with the original patch which uses unsigned ints. I tried changing to unsigned longs. It seemed a little better, though not sure if it was really due to the change. I think unsigned longs should be used for 64-bit boxes. Did you use a benchmark/program that is open source? I don't know that I have anything decent to test this with. Raymond probably does though. Also what platform did you test on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 From noreply at sourceforge.net Sun Jun 10 05:19:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 09 Jun 2007 20:19:35 -0700 Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache optimization updated for Python 2.6 Message-ID: Patches item #1700288, was opened at 2007-04-13 15:16 Message generated for change (Comment added) made by bioinformed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Jacobs (bioinformed) Assigned to: Raymond Hettinger (rhettinger) Summary: Armin's method cache optimization updated for Python 2.6 Initial Comment: I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986). I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up. My performance results are not quite as good as Armin's, though still very encouraging. I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%. Given these rather significant results, the major task is to verify correctness. ---------------------------------------------------------------------- >Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-09 23:19 Message: Logged In: YES user_id=1768698 Originator: YES The cache is global to make it fast, have a deterministic and low memory footprint, and be easy to invalidate. It is distinct from the standard Python dict implementation since it need not be as general nor fully associative, as cache collisions are not subject to re-probing. Neither does it even go through the motions of memory management, which would be rather hard to get the standard dict implementation to emulate. It is kept drastically minimal in the interests of performance and goes to great pains to hide and minimize the impact to the rest of the interpreter. In this regard it seems quite successful, as it even removes the need for the manually inlined code you commented on before. It also survives harsh stress-testing and presents no detectable performance regressions in any of my benchmarks (to the contrary, many operations are significantly faster). While a per-type-object cache sounds feasible, it is hard for me to see how it could be as efficient in the general case -- for one, the dict look up fast path is just so much heavier. Please feel free to take that as a challenge to produce a patch that contradicts my intuition. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 22:48 Message: Logged In: YES user_id=231480 Originator: NO I may be missing something trivial here, but why the cache global - and not per-typeobject? As I saw it - the mro cache was supposed to be a mapping of (type,name)->(descriptor/classattr) that's based on the __mro__ of type, and all of the dicts in type and its bases. I think the right way to do it is to use another Pythonic dict object in each type, that holds this cache (name->(descriptor/classattr)). This cache dict should essentially be equivalent to a merge of all the dicts in the mro. and gets updated whenever any of the dicts of the types in the mro gets updated. Not sure why to re-implement a fast-hashtable when one already exists. Also - once it is associated with the type - it does not hold any references to any names that are not already referenced by someone in the type hierarchy, so there are no mm/gc issues either. Am I missing something here? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-09 22:16 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I'm still reviewing this code. ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-09 22:08 Message: Logged In: YES user_id=1768698 Originator: YES First off, all versions of this patch do away with the rather aggressively repeated inline code. My previous comment about refactoring and testing an inlined form were purely an experiment with null results. That aside, you do raise a good question. However, given the current patch, it is unfortunately off-topic and irrelevant to the consideration of this patch. Please feel free to pursue it elsewhere, since I worry that it will only serve as a negative distraction from the much more interesting aims of the mro optimization. Since you are clearly worried about the performance of attribute lookup, please try it out and report your findings. I'll be happy review the results from your benchmarks and any suggestions you have. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-09 21:16 Message: Logged In: YES user_id=231480 Originator: NO Why is CPython copying functions to inline them? This is not only code duplication that makes the code easy to break, it also bloats the caller function beyond readability. I believe that using a private .c #include file with an inline keyword, or at worst, #include the function code directly is a better solution. Is there any reason to use the method currently used by CPython? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-05-14 16:18 Message: Logged In: YES user_id=1768698 Originator: YES I tried re-inlining the fast path from _PyType_Lookup() in object.c and found no measurable improvement on the simple benchmarks I tried. I've also stress-tested the patch by disabling the fast-path return, always performing the slow-path lookup, and asserting that the cached result matches the slow-path result. I then ran that modified interpreter on the Python test-suite, various benchmarks, and a range of my own applications. While not a formal proof of correctness, it was encouraging that the cache remained consistent. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-05-14 15:12 Message: Logged In: YES user_id=4771 Originator: NO A further minor improvement could be achieved by re-doing the inlining of _PyType_Lookup() in object.c. Ideally, the fast path only could be inlined, and the rest put in a separate function or just using _PyType_Lookup(). ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-04-14 09:49 Message: Logged In: YES user_id=1768698 Originator: YES I benchmarked using pystone, pybench, and a bunch of my local scientific applications that have tight computational kernels still in pure Python. I tested on a 64bit Linux box, defining the version_tag as either int or unsigned long with no appreciable difference in performance. I'm trying to get parrotbench to run, but it doesn't seem to have been updated for modern Python versions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-14 02:21 Message: Logged In: YES user_id=33168 Originator: NO I tried this test on parrotbench (b0.py in particular) and I'm not sure I could distinguish an improvement over the noise (best case was about 5%). The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc 4.1.2-ish). At first it seemed a bit slower with the original patch which uses unsigned ints. I tried changing to unsigned longs. It seemed a little better, though not sure if it was really due to the change. I think unsigned longs should be used for 64-bit boxes. Did you use a benchmark/program that is open source? I don't know that I have anything decent to test this with. Raymond probably does though. Also what platform did you test on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 From noreply at sourceforge.net Sun Jun 10 09:45:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 00:45:29 -0700 Subject: [Patches] [ python-Patches-1700288 ] Armin's method cache optimization updated for Python 2.6 Message-ID: Patches item #1700288, was opened at 2007-04-13 19:16 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Jacobs (bioinformed) Assigned to: Raymond Hettinger (rhettinger) Summary: Armin's method cache optimization updated for Python 2.6 Initial Comment: I've forward ported and slightly cleaned up Armin's method cache patch (see #1685986). I've attempted to clarify and tighten up several loose ends in the code, so hopefully I haven't mucked anything up. My performance results are not quite as good as Armin's, though still very encouraging. I see a typical speed up of 10%, with heavily object oriented application code seeing speedups of 15-20%. Given these rather significant results, the major task is to verify correctness. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2007-06-10 07:45 Message: Logged In: YES user_id=4771 Originator: NO peaker: we tried several approaches (including ones similar to what you describe) in PyPy, and the one in this patch is the one that worked best there. There is of course no guarantee that the same experiments would have given exactly the same results in CPython, so feel free to try them all again - I won't :-) ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-10 03:19 Message: Logged In: YES user_id=1768698 Originator: YES The cache is global to make it fast, have a deterministic and low memory footprint, and be easy to invalidate. It is distinct from the standard Python dict implementation since it need not be as general nor fully associative, as cache collisions are not subject to re-probing. Neither does it even go through the motions of memory management, which would be rather hard to get the standard dict implementation to emulate. It is kept drastically minimal in the interests of performance and goes to great pains to hide and minimize the impact to the rest of the interpreter. In this regard it seems quite successful, as it even removes the need for the manually inlined code you commented on before. It also survives harsh stress-testing and presents no detectable performance regressions in any of my benchmarks (to the contrary, many operations are significantly faster). While a per-type-object cache sounds feasible, it is hard for me to see how it could be as efficient in the general case -- for one, the dict look up fast path is just so much heavier. Please feel free to take that as a challenge to produce a patch that contradicts my intuition. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-10 02:48 Message: Logged In: YES user_id=231480 Originator: NO I may be missing something trivial here, but why the cache global - and not per-typeobject? As I saw it - the mro cache was supposed to be a mapping of (type,name)->(descriptor/classattr) that's based on the __mro__ of type, and all of the dicts in type and its bases. I think the right way to do it is to use another Pythonic dict object in each type, that holds this cache (name->(descriptor/classattr)). This cache dict should essentially be equivalent to a merge of all the dicts in the mro. and gets updated whenever any of the dicts of the types in the mro gets updated. Not sure why to re-implement a fast-hashtable when one already exists. Also - once it is associated with the type - it does not hold any references to any names that are not already referenced by someone in the type hierarchy, so there are no mm/gc issues either. Am I missing something here? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-10 02:16 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I'm still reviewing this code. ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-06-10 02:08 Message: Logged In: YES user_id=1768698 Originator: YES First off, all versions of this patch do away with the rather aggressively repeated inline code. My previous comment about refactoring and testing an inlined form were purely an experiment with null results. That aside, you do raise a good question. However, given the current patch, it is unfortunately off-topic and irrelevant to the consideration of this patch. Please feel free to pursue it elsewhere, since I worry that it will only serve as a negative distraction from the much more interesting aims of the mro optimization. Since you are clearly worried about the performance of attribute lookup, please try it out and report your findings. I'll be happy review the results from your benchmarks and any suggestions you have. ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-10 01:16 Message: Logged In: YES user_id=231480 Originator: NO Why is CPython copying functions to inline them? This is not only code duplication that makes the code easy to break, it also bloats the caller function beyond readability. I believe that using a private .c #include file with an inline keyword, or at worst, #include the function code directly is a better solution. Is there any reason to use the method currently used by CPython? ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-05-14 20:18 Message: Logged In: YES user_id=1768698 Originator: YES I tried re-inlining the fast path from _PyType_Lookup() in object.c and found no measurable improvement on the simple benchmarks I tried. I've also stress-tested the patch by disabling the fast-path return, always performing the slow-path lookup, and asserting that the cached result matches the slow-path result. I then ran that modified interpreter on the Python test-suite, various benchmarks, and a range of my own applications. While not a formal proof of correctness, it was encouraging that the cache remained consistent. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-05-14 19:12 Message: Logged In: YES user_id=4771 Originator: NO A further minor improvement could be achieved by re-doing the inlining of _PyType_Lookup() in object.c. Ideally, the fast path only could be inlined, and the rest put in a separate function or just using _PyType_Lookup(). ---------------------------------------------------------------------- Comment By: Kevin Jacobs (bioinformed) Date: 2007-04-14 13:49 Message: Logged In: YES user_id=1768698 Originator: YES I benchmarked using pystone, pybench, and a bunch of my local scientific applications that have tight computational kernels still in pure Python. I tested on a 64bit Linux box, defining the version_tag as either int or unsigned long with no appreciable difference in performance. I'm trying to get parrotbench to run, but it doesn't seem to have been updated for modern Python versions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-14 06:21 Message: Logged In: YES user_id=33168 Originator: NO I tried this test on parrotbench (b0.py in particular) and I'm not sure I could distinguish an improvement over the noise (best case was about 5%). The variability is pretty high on my box (dual amd64 opertons, ubuntu gcc 4.1.2-ish). At first it seemed a bit slower with the original patch which uses unsigned ints. I tried changing to unsigned longs. It seemed a little better, though not sure if it was really due to the change. I think unsigned longs should be used for 64-bit boxes. Did you use a benchmark/program that is open source? I don't know that I have anything decent to test this with. Raymond probably does though. Also what platform did you test on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1700288&group_id=5470 From noreply at sourceforge.net Sun Jun 10 12:53:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 03:53:22 -0700 Subject: [Patches] [ python-Patches-1734346 ] patch for bug 1170311 "zipfile UnicodeDecodeError" Message-ID: Patches item #1734346, was opened at 2007-06-10 14:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 Please note that this 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 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug 1170311 "zipfile UnicodeDecodeError" Initial Comment: This patch fixes UnicodeDecodeError when attempting to write files to zipfile with filename of unicode class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 From noreply at sourceforge.net Sun Jun 10 12:58:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 03:58:23 -0700 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-27 00:48 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2007-06-10 10:58 Message: Logged In: YES user_id=81797 Originator: NO This code has a number of outstanding issues including (primarily) whether a contributors agreement will be signed. It would be nice to have this code in Distutils, but I think this is a show-stopper to getting it in. If Geoffrey signs a contributor agreement, I'll open it back up and see if I can address the other outstanding issues. Sean ---------------------------------------------------------------------- Comment By: Andrew Straw (astraw) Date: 2007-04-03 03:17 Message: Logged In: YES user_id=210276 Originator: NO You may also be interested in stdeb, which produces Debian source packages from Python packages. See http://stdeb.python-hosting.com/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-28 15:06 Message: Logged In: YES user_id=21627 I agree with most of kbk's comments, except for 5: all of the *_util modules are in distutils, why not deb_util? It is not a command. Also, dairiki, are you willing to sign the contributor form? see http://www.python.org/psf/contrib.html ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-19 23:18 Message: Logged In: YES user_id=149084 In response to jafo's request for comments on python-dev: 1. This facility should be documented in the Python Module docs. A section should be introduced in "Distributing Python Modules" after the 5.2 Creating RPM Packages. Also, the reference disutils.command.bdist_deb should be supplied. The fact that the rest of distutils is 'lightly' documented is no excuse :-) 2. The README.bdist_deb should be folded into the doc strings for the two modules (except the change info should be left behind in the patch). 3. The existing doc strings in the two modules are not always in standard form, and could be more extensive. 4. There are triple quoted block comments in the code. These should be # comment blocks, cf. PEP8 and PEP 257. You don't use doc strings to document variables. 5. deb_util.py probably belongs in distutils/command/ 6. I would like it better if the default was to build the source package, and that would be consistent with bdist_rpm's action. 7. I'm not entirely happy with the overall design: it seems there are two ways to go. First, run bdist_deb, which give you a package which isn't debian compliant; there's no debian/changelog. Second, you can run dh_make, which will 'debianize' the Python source. This can only be done once, and then the recommendation is to use the standard Debian tools to create the packages. In this second case, apparently you can't use bdist_deb, nor do you have a convenient way of updating when the Python code changes, if I understand the README.bdist_deb correctly. If these impressions are correct, it's a lot of code for relatively little effect, at least at its current level of development. 8. What about alberanid's last comment? 8. Do we have a commitment from Dairiki to maintain this code for at least a couple of years? ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2005-02-23 11:10 Message: Logged In: YES user_id=170840 Sometimes you need to install the same package for many different releases of Python; unfortunately this will fail, because dpkg refuses to override the dummy man page, present in both packages. Would it be a good idea to modify line 453 of dh_make to include pyver in the name of the manpage file? ---------------------------------------------------------------------- Comment By: Marek Kubica (leonidasxiv) Date: 2005-01-11 16:53 Message: Logged In: YES user_id=872713 I was looking a long time for something like this. I really hope seeing this in Python 2.5, although I'm not familiar with Python's development process. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-11 16:18 Message: Logged In: YES user_id=45814 Another updated patch set. The only change is a bug fix: when using a hand-build set of debian/* files, dh_make will now deduce the correct Debian revision and build architecture. (Bug reported by Bastian Kleineidam.) Patches, as always are on today's CVS version of distutils. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 15:39 Message: Logged In: YES user_id=170840 I've created a patch to make your bdist_deb/dh_make commands compatible with Python 1.5.2; it can be found here: http://erlug.linux.it/~da/tmp/distutils-cvs_debpy152-20041109.patch Beware that I've tested it for a very short time, so double check everything (especially the permissions on file/umasks). Moreover, the patch changes also some other files like build_py.py, install_lib.py, bdist_rpm.py, that were not 1.5.2 compatible - these changes are part of another patch I've posted today. HTH. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 21:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 22:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 08:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 19:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 14:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-27 03:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Sun Jun 10 13:11:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 04:11:43 -0700 Subject: [Patches] [ python-Patches-1054967 ] bdist_deb - Debian packager Message-ID: Patches item #1054967, was opened at 2004-10-27 02:48 Message generated for change (Comment added) made by alberanid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 Please note that this 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.5 Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Sean Reifschneider (jafo) Summary: bdist_deb - Debian packager Initial Comment: Here's a first crack at a bdist_deb. This patch implements two new distutils commands: bdist_deb: Build Debian packages debianize: Create and populate a top-level debian subdirectory. (Essentially dh_make for distutils packages.) There is a slightly detailed README.bdist_deb included in the patches. I'm open to suggestions for improvements and bug-fixes. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2007-06-10 13:11 Message: Logged In: YES user_id=170840 Originator: NO jafo wrote: > It would be nice to have this code in Distutils Absolutely! I think that a deb packages generator (so policy-compliant as it can be) will be useful to many people. Unfortunately I'm not an expert about debian packages, but maybe I can do some testing and/or write some code. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2007-06-10 12:58 Message: Logged In: YES user_id=81797 Originator: NO This code has a number of outstanding issues including (primarily) whether a contributors agreement will be signed. It would be nice to have this code in Distutils, but I think this is a show-stopper to getting it in. If Geoffrey signs a contributor agreement, I'll open it back up and see if I can address the other outstanding issues. Sean ---------------------------------------------------------------------- Comment By: Andrew Straw (astraw) Date: 2007-04-03 05:17 Message: Logged In: YES user_id=210276 Originator: NO You may also be interested in stdeb, which produces Debian source packages from Python packages. See http://stdeb.python-hosting.com/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-28 17:06 Message: Logged In: YES user_id=21627 I agree with most of kbk's comments, except for 5: all of the *_util modules are in distutils, why not deb_util? It is not a command. Also, dairiki, are you willing to sign the contributor form? see http://www.python.org/psf/contrib.html ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-20 00:18 Message: Logged In: YES user_id=149084 In response to jafo's request for comments on python-dev: 1. This facility should be documented in the Python Module docs. A section should be introduced in "Distributing Python Modules" after the 5.2 Creating RPM Packages. Also, the reference disutils.command.bdist_deb should be supplied. The fact that the rest of distutils is 'lightly' documented is no excuse :-) 2. The README.bdist_deb should be folded into the doc strings for the two modules (except the change info should be left behind in the patch). 3. The existing doc strings in the two modules are not always in standard form, and could be more extensive. 4. There are triple quoted block comments in the code. These should be # comment blocks, cf. PEP8 and PEP 257. You don't use doc strings to document variables. 5. deb_util.py probably belongs in distutils/command/ 6. I would like it better if the default was to build the source package, and that would be consistent with bdist_rpm's action. 7. I'm not entirely happy with the overall design: it seems there are two ways to go. First, run bdist_deb, which give you a package which isn't debian compliant; there's no debian/changelog. Second, you can run dh_make, which will 'debianize' the Python source. This can only be done once, and then the recommendation is to use the standard Debian tools to create the packages. In this second case, apparently you can't use bdist_deb, nor do you have a convenient way of updating when the Python code changes, if I understand the README.bdist_deb correctly. If these impressions are correct, it's a lot of code for relatively little effect, at least at its current level of development. 8. What about alberanid's last comment? 8. Do we have a commitment from Dairiki to maintain this code for at least a couple of years? ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2005-02-23 12:10 Message: Logged In: YES user_id=170840 Sometimes you need to install the same package for many different releases of Python; unfortunately this will fail, because dpkg refuses to override the dummy man page, present in both packages. Would it be a good idea to modify line 453 of dh_make to include pyver in the name of the manpage file? ---------------------------------------------------------------------- Comment By: Marek Kubica (leonidasxiv) Date: 2005-01-11 17:53 Message: Logged In: YES user_id=872713 I was looking a long time for something like this. I really hope seeing this in Python 2.5, although I'm not familiar with Python's development process. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-11 17:18 Message: Logged In: YES user_id=45814 Another updated patch set. The only change is a bug fix: when using a hand-build set of debian/* files, dh_make will now deduce the correct Debian revision and build architecture. (Bug reported by Bastian Kleineidam.) Patches, as always are on today's CVS version of distutils. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-11-09 16:39 Message: Logged In: YES user_id=170840 I've created a patch to make your bdist_deb/dh_make commands compatible with Python 1.5.2; it can be found here: http://erlug.linux.it/~da/tmp/distutils-cvs_debpy152-20041109.patch Beware that I've tested it for a very short time, so double check everything (especially the permissions on file/umasks). Moreover, the patch changes also some other files like build_py.py, install_lib.py, bdist_rpm.py, that were not 1.5.2 compatible - these changes are part of another patch I've posted today. HTH. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-08 22:38 Message: Logged In: YES user_id=45814 Another updated patch set: As suggested by Bastian Kleineidam, when the source distribution includes it's own debian subdirectory, bdist_deb (rather than just crapping out) will now skip the dh_make stage, and just run debuild. As always, patches on the current CVS version of distutils are attached below. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-11-02 23:20 Message: Logged In: YES user_id=45814 Here's try number three! Changes are mostly fixes for woody. The README.bdist_deb (included in the patch set) enumerates the changes in more detail. (I've bitten the bullet and installed woody on one of my machines, so I'm fairly confident it should work now.) The patches, on todays CVS are, as always, attached below. ==== Note to Davide, Thank you, again, very much for all the testing. A couple of the lintian warnings ('prerm-does-not-remove-usr-doc-link' and 'postinst-does-not-set-usr-doc-link') that are listed in your test suite output are due, I think, to your mixed system. Specifically, I suspect you've got the woody version of lintian (which wants to see symlinks from /usr/doc/ to /usr/share/doc/), but a later version of debhelper. (Woody's dh_installdocs (in the debhelper package) automatically generates those links, later versions don't; /usr/doc has been phased out.) Anyhow, I'm not going to fix those warnings (unless it turns out that you're seeing them on your pure woody system.) On package with python scripts (in /usr/bin) Woody's lintian generates an 'unusual-interpreter' warning which I think is spurious (i.e. it is not a valid warning.) (Lintian 1.20.17 doesn't recognize things like /usr/bin/python2.1 as a valid interpreter --- it seems valid enough to me.) Best Regards, Jeff ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-30 10:57 Message: Logged In: YES user_id=170840 I've tried the 29/10 patch with my home system (dpkg-dev 1.10, debhelper 4.1.90 and dh-make 0.30) and another "pure woody" system (dpkg-dev 1.9.21, debhelper 4.0.2 and dh-make 0.30). I've used your test suite and some of my personal projects (using both bdist_deb and dh_make); as far as I can tell, it works very well. :-) bdist_deb always worked as expected, producing good debian packages. I've used dh_make and then I've run "dpkg-buildpackage -rfakeroot" and I got some errors (but I'm not sure they depends on your code). Also your test suite produced some failures. Here you can find the output of "dpkg-buildpackage -rfakeroot" and of your tests suite (both were running on my home system): http://erlug.linux.it/~da/tmp/dpkg-buildpackage http://erlug.linux.it/~da/tmp/testsuite Thank you for your great effort! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2004-10-29 21:38 Message: Logged In: YES user_id=45814 Thanks for the comments. Here's a second attempt. Changes include: It might work with woody. (I'd appreciate it if you could try again, Davide) 'debianize' command renamed to 'dh_make'. Use debchange to create debian/changelog. This eliminates the need to duplicate debchange's logic to deduce the packagers name and e-mail. A more complete test script. Patches are on today's CVS. ---------------------------------------------------------------------- Comment By: Davide Alberani (alberanid) Date: 2004-10-27 16:47 Message: Logged In: YES user_id=170840 I've a woody with some packages backported from sarge (debhelper 4.1.90 and dpkg-dev 1.10). Running python2.3 ./setup.py bdist_deb with some of my projects, I got the error: dpkg-buildpackage: unknown option or argument --check-dirname-level=1 Debian dpkg-buildpackage . Commenting out the "check-dirname-level" and "check-dirname-regex" options in the bdist_deb.py file the script can go on, but it exits with the error: debian/rules:11: *** first argument to `word' function must be greater than 0. Stop. Hope this helps. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2004-10-27 05:44 Message: Logged In: YES user_id=81797 I'm just doing a review of this code. A couple of things: There's been some concern expressed about get_default_maintainer. Namely, that if debchange changes it's algorithm, it won't be reflected in this code. It seems like one possible way around that would be to build a directory with a "debian" directory under it, a fake "changelog", and then call debchange to write the data out, and parse it. Too bad there's not a direct hook into debchange to get that information. Can _formatdate, if email doesn't exist, use rfc822.formatdate()? Ditto for _parseaddr? It looks pretty good. However, when trying to build a .deb of my jotweb2 package, it's failing with: [...] dh_testdir dh_testroot dh_installchangelogs- dh_installdocs cp: cannot stat `doc': No such file or directory dh_installdocs: command returned error code 256 [...] I'm not sure exactly why. I do have a "doc" directory in my main package directory, but I don't reference to it in my setup.py or MANIFEST. Adding it to the MANIFEST doesn't seem to help this. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1054967&group_id=5470 From noreply at sourceforge.net Sun Jun 10 18:48:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 09:48:10 -0700 Subject: [Patches] [ python-Patches-1734346 ] patch for bug 1170311 "zipfile UnicodeDecodeError" Message-ID: Patches item #1734346, was opened at 2007-06-10 12:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 Please note that this 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 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug 1170311 "zipfile UnicodeDecodeError" Initial Comment: This patch fixes UnicodeDecodeError when attempting to write files to zipfile with filename of unicode class. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-10 18:48 Message: Logged In: YES user_id=21627 Originator: NO This patch is incorrect. It relies on the system encoding, and allows non-string things as file names. What it really should do is to encode in code page 437; bonus points if it falls back to the UTF-8 feature of zip files when that encoding fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 From noreply at sourceforge.net Sun Jun 10 22:29:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 13:29:54 -0700 Subject: [Patches] [ python-Patches-1734346 ] patch for bug 1170311 "zipfile UnicodeDecodeError" Message-ID: Patches item #1734346, was opened at 2007-06-10 14:53 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 Please note that this 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 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug 1170311 "zipfile UnicodeDecodeError" Initial Comment: This patch fixes UnicodeDecodeError when attempting to write files to zipfile with filename of unicode class. ---------------------------------------------------------------------- >Comment By: Alexey Borzenkov (snaury) Date: 2007-06-11 00:29 Message: Logged In: YES user_id=1197042 Originator: YES File Added: python-zipfile-unicode-filenames-utf8.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-10 20:48 Message: Logged In: YES user_id=21627 Originator: NO This patch is incorrect. It relies on the system encoding, and allows non-string things as file names. What it really should do is to encode in code page 437; bonus points if it falls back to the UTF-8 feature of zip files when that encoding fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 From noreply at sourceforge.net Mon Jun 11 06:22:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 21:22:53 -0700 Subject: [Patches] [ python-Patches-1734346 ] patch for bug 1170311 "zipfile UnicodeDecodeError" Message-ID: Patches item #1734346, was opened at 2007-06-10 14:53 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 Please note that this 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 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug 1170311 "zipfile UnicodeDecodeError" Initial Comment: This patch fixes UnicodeDecodeError when attempting to write files to zipfile with filename of unicode class. ---------------------------------------------------------------------- >Comment By: Alexey Borzenkov (snaury) Date: 2007-06-11 08:22 Message: Logged In: YES user_id=1197042 Originator: YES File Added: python-zipfile-unicode-filenames-utf8-2.patch ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2007-06-11 00:29 Message: Logged In: YES user_id=1197042 Originator: YES File Added: python-zipfile-unicode-filenames-utf8.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-10 20:48 Message: Logged In: YES user_id=21627 Originator: NO This patch is incorrect. It relies on the system encoding, and allows non-string things as file names. What it really should do is to encode in code page 437; bonus points if it falls back to the UTF-8 feature of zip files when that encoding fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 From noreply at sourceforge.net Mon Jun 11 06:27:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 10 Jun 2007 21:27:33 -0700 Subject: [Patches] [ python-Patches-1734346 ] patch for bug 1170311 "zipfile UnicodeDecodeError" Message-ID: Patches item #1734346, was opened at 2007-06-10 14:53 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 Please note that this 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 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: patch for bug 1170311 "zipfile UnicodeDecodeError" Initial Comment: This patch fixes UnicodeDecodeError when attempting to write files to zipfile with filename of unicode class. ---------------------------------------------------------------------- >Comment By: Alexey Borzenkov (snaury) Date: 2007-06-11 08:27 Message: Logged In: YES user_id=1197042 Originator: YES File Added: python-zipfile-unicode-filenames-utf8-3.patch ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2007-06-11 08:22 Message: Logged In: YES user_id=1197042 Originator: YES File Added: python-zipfile-unicode-filenames-utf8-2.patch ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2007-06-11 00:29 Message: Logged In: YES user_id=1197042 Originator: YES File Added: python-zipfile-unicode-filenames-utf8.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-06-10 20:48 Message: Logged In: YES user_id=21627 Originator: NO This patch is incorrect. It relies on the system encoding, and allows non-string things as file names. What it really should do is to encode in code page 437; bonus points if it falls back to the UTF-8 feature of zip files when that encoding fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734346&group_id=5470 From noreply at sourceforge.net Mon Jun 11 14:08:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 05:08:45 -0700 Subject: [Patches] [ python-Patches-1734945 ] platform.py patch to support turbolinux Message-ID: Patches item #1734945, was opened at 2007-06-11 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734945&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yayati_Turbolinux (yayati_turbo) Assigned to: Nobody/Anonymous (nobody) Summary: platform.py patch to support turbolinux Initial Comment: HI, Please find below a small patch to support Turbolinux Distributions. Thanks, Yayati. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734945&group_id=5470 From noreply at sourceforge.net Mon Jun 11 14:09:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 05:09:18 -0700 Subject: [Patches] [ python-Patches-1734945 ] platform.py patch to support turbolinux Message-ID: Patches item #1734945, was opened at 2007-06-11 12:08 Message generated for change (Settings changed) made by yayati_turbo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734945&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yayati_Turbolinux (yayati_turbo) >Assigned to: M.-A. Lemburg (lemburg) Summary: platform.py patch to support turbolinux Initial Comment: HI, Please find below a small patch to support Turbolinux Distributions. Thanks, Yayati. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734945&group_id=5470 From noreply at sourceforge.net Mon Jun 11 16:06:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 07:06:55 -0700 Subject: [Patches] [ python-Patches-1735030 ] Fix selectmodule.c compilation on GNU/Hurd Message-ID: Patches item #1735030, was opened at 2007-06-11 16: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=1735030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Banck (mbanck) Assigned to: Nobody/Anonymous (nobody) Summary: Fix selectmodule.c compilation on GNU/Hurd Initial Comment: This patch (by Wouter van Heyst) fixes compilation of python2.5 on the Hurd (and other systems?) It fixes the following build error: gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/build/buildd/python2.5-2.5/./Include -I../Include -I. -I/build/buildd/python2.5-2.5/Include -I/build/buildd/python2.5-2.5/build-static -c /build/buildd/python2.5-2.5/Modules/selectmodule.c -o build/temp.gnu-0.3-i686-AT386-2.5/build/buildd/python2.5-2.5/Modules/selectmodule.o /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'select_poll' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'poll_doc' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c: In function 'initselect': /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: 'poll_Type' undeclared (first use in this function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: (Each undeclared identifier is reported only once /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: for each function it appears in.) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: request for member 'ob_type' in something not a structure or union /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: warning: statement with no effect We hope this does not break other platforms, does this look OK? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 From noreply at sourceforge.net Mon Jun 11 23:20:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 14:20:02 -0700 Subject: [Patches] [ python-Patches-1727209 ] First steps towards new super (PEP 3135) Message-ID: Patches item #1727209, was opened at 2007-05-28 22:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) >Summary: First steps towards new super (PEP 3135) Initial Comment: A half-assed start of an implementation for super. This is lacking parser support; instead, for now, you have to have a keyword-only argument named super, e.g. def foo(self, arg, *, super): return super.foo(arg) + 1 Note that the first version changes method lookup for bound method lookup but not yet for unbound method lookup. E.g. if f is defined in class B, and class C derives from B, C().f returns a bound method object whose im_class attribute is set to B (as opposed to C as it used to be) but C.f returns an unbound method object with im_class set to C. (I hope to this in a later version.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-11 17:20 Message: Logged In: YES user_id=6380 Originator: YES I've checked this into the p3yk branch now. Tim Delaney will update the PEP. Note that the PEP number has changed; it's 3135 now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 17:00 Message: Logged In: YES user_id=6380 Originator: YES Sorry, forgot to add test_super.py to the patch. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:57 Message: Logged In: YES user_id=6380 Originator: YES OK, here's today's final version (I hope). This fixes test_scope.py (wasn't too hard after all) and updates the docstring for super(). Question to all: is writing super() acceptable? File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 16:01 Message: Logged In: YES user_id=6380 Originator: YES Here's a better version that lets you use super() as a shorthand for super(__class__, ). test_scope.py still fails though. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-06-06 14:53 Message: Logged In: YES user_id=6380 Originator: YES I'm starting a new series of patches, super2.diff. These use a completely different tack, inserting a cell variable __class__ into the class shared by all the methods and initialized to the class after it's constructed. Right now, this allows us to write super(__class__, self).method() -- I want to evolve it so that eventually you can write super.method() and super will do the lookup of __class__ and the first argument itself. There's one failing test, testFreeVarInMethod in test_scope.py. This seems significant but I want to upload a checkpoint first. File Added: super2.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 19:00 Message: Logged In: YES user_id=6380 Originator: YES This breaks all class methods (as Phillip Eby pointed out): class C: @classmethod def cm(cls): return cls.__name__ class D(C): pass print(D.cm(), D().cm()) This should print "D D" but with the patch it prints "C C". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:45 Message: Logged In: YES user_id=6380 Originator: YES Oops, a last-minute change didn't work out. This version is better. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-31 07:24 Message: Logged In: YES user_id=6380 Originator: YES Here's a version that modifies the grammar so 'super' is a keyword. The compiler automatically inserts a 'super' keyword-only argument into a function's signature when the 'super' keyword is used in its body. It works! This requires the p3yk branch at -r55692 or newer. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-29 02:08 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version. Forget about sup.py, the demos are now in Lib/test/test_super.py. Only a few tests fail due to the semantic change (about six files have 1-2 failures each). I think this is acceptable. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:23 Message: Logged In: YES user_id=6380 Originator: YES And a new sup.py example demonstrating that the new patch works. File Added: sup.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 23:22 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version of the patch where C.f.im_class (in the above example) correctly returns B. File Added: super.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-28 22:31 Message: Logged In: YES user_id=6380 Originator: YES Here is sup.py, a small demo of how this is supposed to work. File Added: sup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1727209&group_id=5470 From noreply at sourceforge.net Tue Jun 12 04:54:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 19:54:00 -0700 Subject: [Patches] [ python-Patches-1735030 ] Fix selectmodule.c compilation on GNU/Hurd Message-ID: Patches item #1735030, was opened at 2007-06-11 07:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Banck (mbanck) Assigned to: Nobody/Anonymous (nobody) Summary: Fix selectmodule.c compilation on GNU/Hurd Initial Comment: This patch (by Wouter van Heyst) fixes compilation of python2.5 on the Hurd (and other systems?) It fixes the following build error: gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/build/buildd/python2.5-2.5/./Include -I../Include -I. -I/build/buildd/python2.5-2.5/Include -I/build/buildd/python2.5-2.5/build-static -c /build/buildd/python2.5-2.5/Modules/selectmodule.c -o build/temp.gnu-0.3-i686-AT386-2.5/build/buildd/python2.5-2.5/Modules/selectmodule.o /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'select_poll' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'poll_doc' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c: In function 'initselect': /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: 'poll_Type' undeclared (first use in this function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: (Each undeclared identifier is reported only once /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: for each function it appears in.) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: request for member 'ob_type' in something not a structure or union /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: warning: statement with no effect We hope this does not break other platforms, does this look OK? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-11 19:54 Message: Logged In: YES user_id=33168 Originator: NO Is this only change required for Hurd? I'm not sure, but HAVE_BROKEN_POLL might have a specific meaning on OS X. So there might be a problem with this patch. I'd need to look at the whole file to verify. I'll try to remember to do that later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 From noreply at sourceforge.net Tue Jun 12 06:50:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 21:50:58 -0700 Subject: [Patches] [ python-Patches-1735485 ] Kill StandardError Message-ID: Patches item #1735485, was opened at 2007-06-12 00:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735485&group_id=5470 Please note that this 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 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Neal Norwitz (nnorwitz) Summary: Kill StandardError Initial Comment: Per PEP 3100, remove StandardError from the exception hierarchy. Neal, can you give this a quick look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735485&group_id=5470 From noreply at sourceforge.net Tue Jun 12 08:14:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 11 Jun 2007 23:14:44 -0700 Subject: [Patches] [ python-Patches-1735485 ] Kill StandardError Message-ID: Patches item #1735485, was opened at 2007-06-11 21:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735485&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) >Assigned to: Collin Winter (collinwinter) Summary: Kill StandardError Initial Comment: Per PEP 3100, remove StandardError from the exception hierarchy. Neal, can you give this a quick look? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-11 23:14 Message: Logged In: YES user_id=33168 Originator: NO I only saw 2 things. Otherwise, lgtm. There are two duplicated lines for Exception: PRE_INIT(Exception) - PRE_INIT(StandardError) + PRE_INIT(Exception) \versionchanged (or added) shouldn't have a period at the end of the sentence. It will be added automatically. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735485&group_id=5470 From noreply at sourceforge.net Tue Jun 12 11:10:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 02:10:17 -0700 Subject: [Patches] [ python-Patches-1734945 ] platform.py patch to support turbolinux Message-ID: Patches item #1734945, was opened at 2007-06-11 14:08 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734945&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Yayati_Turbolinux (yayati_turbo) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.py patch to support turbolinux Initial Comment: HI, Please find below a small patch to support Turbolinux Distributions. Thanks, Yayati. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 11:10 Message: Logged In: YES user_id=38388 Originator: NO Committed revision 55926. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734945&group_id=5470 From noreply at sourceforge.net Tue Jun 12 11:27:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 02:27:17 -0700 Subject: [Patches] [ python-Patches-1726668 ] platform.system() returns incorrect value in Vista Message-ID: Patches item #1726668, was opened at 2007-05-28 03:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470 Please note that this 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: None Priority: 5 Private: No Submitted By: Benjamin Leppard (bleppard) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.system() returns incorrect value in Vista Initial Comment: On Microsoft Vista platform.system() returns 'Microsoft' and platform.release() returns 'Windows' Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and platform.release() returns 'XP'. This is problem was caused by a change in the output of the "ver" command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP [Version 5.1.2600]' In Microsoft Vista "ver" outputted 'Microsoft Windows [Version 6.0.6000]'. The lack of the 3rd word before version causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system instead of 'Microsoft Windows'. This causes uname() to return the incorrect values. Both system() and release() call uname(). This problem occurs in the trunk. I have attached a patch against the trunk svn that fixes the symptom of the problem in uname() ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 11:27 Message: Logged In: YES user_id=38388 Originator: NO Thank you. Committed revision 55927. ---------------------------------------------------------------------- Comment By: Benjamin Leppard (bleppard) Date: 2007-05-30 08:04 Message: Logged In: YES user_id=1802829 Originator: YES I updated the patch to included comments, and set the release to 'Vista' when the version starts with '6.0'. Unfortunately both Windows Server 2008 and Windows Vista both are version 6.0. I updated win32_ver() to report the correct values for Vista and Windows Server 2008. It reports release of '2008Server' for Windows 2008 server, and release of 'post2008Server' for version 6.1 or greater. I have not tested it under Windows Server 2008. File Added: Platform-VistaFix2.patch ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-05-29 18:08 Message: Logged In: YES user_id=38388 Originator: NO I don't have Vista handy to check the patch. Ideally, win32_ver() should be patched to return proper values for Vista directly from the registry. Would be great if you could provide a patch for this as well. However, in some cases _syscmd_ver() will still be used, so the patch is fine. Please add a comment explaining the problem and also add a check to set release to 'Vista' in case the version starts with '6.0'. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-05-29 07:11 Message: Logged In: YES user_id=21627 Originator: NO Reclassifying as a patch. Marc-Andre, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726668&group_id=5470 From noreply at sourceforge.net Tue Jun 12 11:33:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 02:33:12 -0700 Subject: [Patches] [ python-Patches-1620174 ] Improve platform.py usability on Windows Message-ID: Patches item #1620174, was opened at 2006-12-21 15:49 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1620174&group_id=5470 Please note that this 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 Private: No Submitted By: Luke Dunstan (infidel) Assigned to: M.-A. Lemburg (lemburg) Summary: Improve platform.py usability on Windows Initial Comment: This patch modifies platform.py to remove most of the dependencies on pywin32, and use the standard ctypes and _winreg modules instead. It also adds support for Windows CE. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2007-06-12 11:33 Message: Logged In: YES user_id=38388 Originator: NO Please update the patch to: * not change the APIs of public interfaces * support both the win32 extension and the combination _winreg and ctypes * work on all Python versions since Python 1.5.2 Otherwise, I'll have to reject the patch. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2007-01-14 00:21 Message: Logged In: YES user_id=38388 Originator: NO platform.py is used outside the Python distribution to check which Python version is being used (among other things). It has to run with Python versions as early as 1.5.2. That said, it's OK to have it use different ways of accessing the needed information, provided that the signatures and return values of the public APIs don't change. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2007-01-01 07:25 Message: Logged In: YES user_id=30442 Originator: YES Why does platform.py need to be compatible with earlier versions of Python? The return types haven't changed, and I think the return values won't change because the same OS APIs are being used. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-12-31 19:49 Message: Logged In: YES user_id=38388 Originator: NO I haven't looked at the patch yet, so just a few general comments on changes to platform.py: * the code must continue to work with Python versions prior to 2.6 This means that ctypes and _winreg support may be added as an option, but removing pywin32 calls is not the right way to proceed. * changes in return type of the public and documented APIs are not possible If you have a need for more information, then a new API should be added, or the information merged into one of the existing return fields. * changes in the return values of APIs due to use of different OS APIs must be avoided There's code out there relying on the return values, so if in doubt a new API must be provided. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-12-31 06:57 Message: Logged In: YES user_id=30442 Originator: YES 1. Yes this is intended for 2.6 2. The only difference between win32api.RegQueryValueEx and _winreg.QueryValueEx seems to be that the latter returns Unicode strings. I have adjusted the patch to be more compatible with the old behaviour. 3. I have updated the doc string in the new patch. File Added: platform-wince-2.diff ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:13 Message: Logged In: YES user_id=764593 Originator: NO ( win32api.RegQueryValueEx is _winreg.QueryValueEx ) ? If not, it should wait for 2.6, and there should be an entry in what's new. (I suppose similar concerns exist for other return classes.) The change to win32_ver only half-corrects the return type to the four-tuple. The meaning of release (even if it is just "release name") should be specified in the text. def win32_ver(release='',version='',csd='',ptype=''): """ Get additional version information from the Windows Registry - and return a tuple (version,csd,ptype) referring to version + and return a tuple (release,version,csd,ptype) referring to version number, CSD level and OS type (multi/single processor). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1620174&group_id=5470 From noreply at sourceforge.net Tue Jun 12 14:55:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 05:55:18 -0700 Subject: [Patches] [ python-Patches-1735030 ] Fix selectmodule.c compilation on GNU/Hurd Message-ID: Patches item #1735030, was opened at 2007-06-11 16:06 Message generated for change (Comment added) made by mbanck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Banck (mbanck) Assigned to: Nobody/Anonymous (nobody) Summary: Fix selectmodule.c compilation on GNU/Hurd Initial Comment: This patch (by Wouter van Heyst) fixes compilation of python2.5 on the Hurd (and other systems?) It fixes the following build error: gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/build/buildd/python2.5-2.5/./Include -I../Include -I. -I/build/buildd/python2.5-2.5/Include -I/build/buildd/python2.5-2.5/build-static -c /build/buildd/python2.5-2.5/Modules/selectmodule.c -o build/temp.gnu-0.3-i686-AT386-2.5/build/buildd/python2.5-2.5/Modules/selectmodule.o /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'select_poll' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'poll_doc' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c: In function 'initselect': /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: 'poll_Type' undeclared (first use in this function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: (Each undeclared identifier is reported only once /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: for each function it appears in.) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: request for member 'ob_type' in something not a structure or union /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: warning: statement with no effect We hope this does not break other platforms, does this look OK? ---------------------------------------------------------------------- >Comment By: Michael Banck (mbanck) Date: 2007-06-12 14:55 Message: Logged In: YES user_id=196016 Originator: YES Yes, python2.5 builds fine otherwise (at least the Debian package, I am not sure whether we applied local changes earlier). This HAVE_BROKEN_POLL issue was the only regression from python2.4 as far as the Debian GNU/Hurd port was concerned. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-12 04:54 Message: Logged In: YES user_id=33168 Originator: NO Is this only change required for Hurd? I'm not sure, but HAVE_BROKEN_POLL might have a specific meaning on OS X. So there might be a problem with this patch. I'd need to look at the whole file to verify. I'll try to remember to do that later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 From noreply at sourceforge.net Tue Jun 12 23:07:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 14:07:43 -0700 Subject: [Patches] [ python-Patches-1735485 ] Kill StandardError Message-ID: Patches item #1735485, was opened at 2007-06-12 00:50 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735485&group_id=5470 Please note that this 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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Kill StandardError Initial Comment: Per PEP 3100, remove StandardError from the exception hierarchy. Neal, can you give this a quick look? ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-06-12 17:07 Message: Logged In: YES user_id=1344176 Originator: YES Checked in as r55939. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-12 02:14 Message: Logged In: YES user_id=33168 Originator: NO I only saw 2 things. Otherwise, lgtm. There are two duplicated lines for Exception: PRE_INIT(Exception) - PRE_INIT(StandardError) + PRE_INIT(Exception) \versionchanged (or added) shouldn't have a period at the end of the sentence. It will be added automatically. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735485&group_id=5470 From noreply at sourceforge.net Tue Jun 12 23:10:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 14:10:35 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 23:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Tue Jun 12 23:13:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 14:13:39 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 23:10 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- >Comment By: billiejoex (billiejoex) Date: 2007-06-12 23:13 Message: Logged In: YES user_id=1357589 Originator: YES client ====== import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 21)) s.send("sumthin") server ====== import asyncore, asynchat import socket import time class Handler(asynchat.async_chat): def __init__(self, server, sock, addr): asynchat.async_chat.__init__(self, sock) self.set_terminator("\n") self.data = "" self.respond("Hey there!\r\n") def respond(self, data): print "->" + data time.sleep(1) self.push(data) def collect_incoming_data(self, data): print "<-" + data self.data = self.data + data def found_terminator(self): self.respond(self.data) self.data = '' def handle_close(self): remote_ip, remote_port = self.socket.getpeername() print "%s:%s disconnected" %(remote_ip, remote_port) self.close() def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self, address): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(address) self.listen(5) def handle_accept(self): conn, addr = self.accept() Handler(self, conn, addr) address = ('', 21) Server(address) print "server ready." asyncore.loop() proposed patch ============== --- line 55 - from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ - ENOTCONN, ESHUTDOWN, EINTR, EISCONN, errorcode + from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ + ENOTCONN, ESHUTDOWN, EINTR, EISCONN, ECONNABORTED, errorcode --- line 329 def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] == ECONNABORTED: + self.handle_close() + return 0 else: raise return 0 --- line 340 def recv(self, buffer_size): try: data = self.socket.recv(buffer_size) if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return '' else: return data except socket.error, why: # winsock sometimes throws ENOTCONN - if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: + if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED]: self.handle_close() return '' else: raise ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Tue Jun 12 23:14:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 14:14:26 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 23:10 Message generated for change (Settings changed) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-12 23:13 Message: Logged In: YES user_id=1357589 Originator: YES client ====== import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 21)) s.send("sumthin") server ====== import asyncore, asynchat import socket import time class Handler(asynchat.async_chat): def __init__(self, server, sock, addr): asynchat.async_chat.__init__(self, sock) self.set_terminator("\n") self.data = "" self.respond("Hey there!\r\n") def respond(self, data): print "->" + data time.sleep(1) self.push(data) def collect_incoming_data(self, data): print "<-" + data self.data = self.data + data def found_terminator(self): self.respond(self.data) self.data = '' def handle_close(self): remote_ip, remote_port = self.socket.getpeername() print "%s:%s disconnected" %(remote_ip, remote_port) self.close() def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self, address): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(address) self.listen(5) def handle_accept(self): conn, addr = self.accept() Handler(self, conn, addr) address = ('', 21) Server(address) print "server ready." asyncore.loop() proposed patch ============== --- line 55 - from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ - ENOTCONN, ESHUTDOWN, EINTR, EISCONN, errorcode + from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ + ENOTCONN, ESHUTDOWN, EINTR, EISCONN, ECONNABORTED, errorcode --- line 329 def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] == ECONNABORTED: + self.handle_close() + return 0 else: raise return 0 --- line 340 def recv(self, buffer_size): try: data = self.socket.recv(buffer_size) if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return '' else: return data except socket.error, why: # winsock sometimes throws ENOTCONN - if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: + if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED]: self.handle_close() return '' else: raise ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Wed Jun 13 02:37:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 17:37:23 -0700 Subject: [Patches] [ python-Patches-1736190 ] asyncore/asynchat patches Message-ID: Patches item #1736190, was opened at 2007-06-12 17:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470 Please note that this 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 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore/asynchat patches Initial Comment: There are a handful of outstanding asyncore/asynchat related bugs in the tracker. This patch seeks to handle all of the issues with the exception of windows-specific socket errors from 658749 . In particular, it takes pieces of patches 909005 and 1736101, to address some issues raised there, as well as the bugs: 539444, 760475, 777588, 889153, 953599, 1025525, and 1063924. In some cases where it could potentially handle fewer exceptions (see the send method), I have opted to handle more of them due to testing actually producing them. It adds test cases from patch 909005. It adds two new sample methods to asynchat.async_chat _get_data and _collect_incoming_data to be used as examples for handling incoming buffers. It removes the simple_producer and fifo classes from asynchat, but accepts work-alikes to the asynchat.async_chat.push_with_producer method. It further fixes an unreported violated invariant in asynchat.async_chat.handle_read() . It also produces a useful error message when asyncore.dispatcher.handle_expt_evt is called if the base handle_expt has not been overwritten. This patch should be applied to the trunk. The new methods, and removal of the two classes should not be included in patches to 2.5 maintenance (don't add the methods and don't remove the classes). Basically everything else should work as it did before (with better error handling), unless someone was monkey-patching asyncore.dispatcher.handle_expt . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470 From noreply at sourceforge.net Wed Jun 13 02:38:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 17:38:27 -0700 Subject: [Patches] [ python-Patches-1736190 ] asyncore/asynchat patches Message-ID: Patches item #1736190, was opened at 2007-06-12 17:37 Message generated for change (Settings changed) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470 Please note that this 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 Private: No Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore/asynchat patches Initial Comment: There are a handful of outstanding asyncore/asynchat related bugs in the tracker. This patch seeks to handle all of the issues with the exception of windows-specific socket errors from 658749 . In particular, it takes pieces of patches 909005 and 1736101, to address some issues raised there, as well as the bugs: 539444, 760475, 777588, 889153, 953599, 1025525, and 1063924. In some cases where it could potentially handle fewer exceptions (see the send method), I have opted to handle more of them due to testing actually producing them. It adds test cases from patch 909005. It adds two new sample methods to asynchat.async_chat _get_data and _collect_incoming_data to be used as examples for handling incoming buffers. It removes the simple_producer and fifo classes from asynchat, but accepts work-alikes to the asynchat.async_chat.push_with_producer method. It further fixes an unreported violated invariant in asynchat.async_chat.handle_read() . It also produces a useful error message when asyncore.dispatcher.handle_expt_evt is called if the base handle_expt has not been overwritten. This patch should be applied to the trunk. The new methods, and removal of the two classes should not be included in patches to 2.5 maintenance (don't add the methods and don't remove the classes). Basically everything else should work as it did before (with better error handling), unless someone was monkey-patching asyncore.dispatcher.handle_expt . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736190&group_id=5470 From noreply at sourceforge.net Wed Jun 13 02:40:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 12 Jun 2007 17:40:47 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 14:10 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-12 17:40 Message: Logged In: YES user_id=341410 Originator: NO Please see python.org/sf/1736190 for a patch that includes this particular bugfixe to asyncore, among others. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-12 14:13 Message: Logged In: YES user_id=1357589 Originator: YES client ====== import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 21)) s.send("sumthin") server ====== import asyncore, asynchat import socket import time class Handler(asynchat.async_chat): def __init__(self, server, sock, addr): asynchat.async_chat.__init__(self, sock) self.set_terminator("\n") self.data = "" self.respond("Hey there!\r\n") def respond(self, data): print "->" + data time.sleep(1) self.push(data) def collect_incoming_data(self, data): print "<-" + data self.data = self.data + data def found_terminator(self): self.respond(self.data) self.data = '' def handle_close(self): remote_ip, remote_port = self.socket.getpeername() print "%s:%s disconnected" %(remote_ip, remote_port) self.close() def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self, address): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(address) self.listen(5) def handle_accept(self): conn, addr = self.accept() Handler(self, conn, addr) address = ('', 21) Server(address) print "server ready." asyncore.loop() proposed patch ============== --- line 55 - from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ - ENOTCONN, ESHUTDOWN, EINTR, EISCONN, errorcode + from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ + ENOTCONN, ESHUTDOWN, EINTR, EISCONN, ECONNABORTED, errorcode --- line 329 def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] == ECONNABORTED: + self.handle_close() + return 0 else: raise return 0 --- line 340 def recv(self, buffer_size): try: data = self.socket.recv(buffer_size) if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return '' else: return data except socket.error, why: # winsock sometimes throws ENOTCONN - if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: + if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED]: self.handle_close() return '' else: raise ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Wed Jun 13 21:03:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 12:03:23 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 23:10 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- >Comment By: billiejoex (billiejoex) Date: 2007-06-13 21:03 Message: Logged In: YES user_id=1357589 Originator: YES Hi, I've seen your patch but it seems to me that it doesn't include ECONNABORTED handling for send method. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-13 02:40 Message: Logged In: YES user_id=341410 Originator: NO Please see python.org/sf/1736190 for a patch that includes this particular bugfixe to asyncore, among others. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-12 23:13 Message: Logged In: YES user_id=1357589 Originator: YES client ====== import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 21)) s.send("sumthin") server ====== import asyncore, asynchat import socket import time class Handler(asynchat.async_chat): def __init__(self, server, sock, addr): asynchat.async_chat.__init__(self, sock) self.set_terminator("\n") self.data = "" self.respond("Hey there!\r\n") def respond(self, data): print "->" + data time.sleep(1) self.push(data) def collect_incoming_data(self, data): print "<-" + data self.data = self.data + data def found_terminator(self): self.respond(self.data) self.data = '' def handle_close(self): remote_ip, remote_port = self.socket.getpeername() print "%s:%s disconnected" %(remote_ip, remote_port) self.close() def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self, address): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(address) self.listen(5) def handle_accept(self): conn, addr = self.accept() Handler(self, conn, addr) address = ('', 21) Server(address) print "server ready." asyncore.loop() proposed patch ============== --- line 55 - from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ - ENOTCONN, ESHUTDOWN, EINTR, EISCONN, errorcode + from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ + ENOTCONN, ESHUTDOWN, EINTR, EISCONN, ECONNABORTED, errorcode --- line 329 def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] == ECONNABORTED: + self.handle_close() + return 0 else: raise return 0 --- line 340 def recv(self, buffer_size): try: data = self.socket.recv(buffer_size) if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return '' else: return data except socket.error, why: # winsock sometimes throws ENOTCONN - if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: + if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED]: self.handle_close() return '' else: raise ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Wed Jun 13 23:13:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 14:13:10 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 14:10 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-13 14:13 Message: Logged In: YES user_id=341410 Originator: NO Re-read the patch. In particular... @@ -333,9 +349,11 @@ except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] in (ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED): + self.handle_close() + return 0 That is added handling for all four potential errors in send. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-13 12:03 Message: Logged In: YES user_id=1357589 Originator: YES Hi, I've seen your patch but it seems to me that it doesn't include ECONNABORTED handling for send method. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-12 17:40 Message: Logged In: YES user_id=341410 Originator: NO Please see python.org/sf/1736190 for a patch that includes this particular bugfixe to asyncore, among others. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-12 14:13 Message: Logged In: YES user_id=1357589 Originator: YES client ====== import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 21)) s.send("sumthin") server ====== import asyncore, asynchat import socket import time class Handler(asynchat.async_chat): def __init__(self, server, sock, addr): asynchat.async_chat.__init__(self, sock) self.set_terminator("\n") self.data = "" self.respond("Hey there!\r\n") def respond(self, data): print "->" + data time.sleep(1) self.push(data) def collect_incoming_data(self, data): print "<-" + data self.data = self.data + data def found_terminator(self): self.respond(self.data) self.data = '' def handle_close(self): remote_ip, remote_port = self.socket.getpeername() print "%s:%s disconnected" %(remote_ip, remote_port) self.close() def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self, address): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(address) self.listen(5) def handle_accept(self): conn, addr = self.accept() Handler(self, conn, addr) address = ('', 21) Server(address) print "server ready." asyncore.loop() proposed patch ============== --- line 55 - from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ - ENOTCONN, ESHUTDOWN, EINTR, EISCONN, errorcode + from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ + ENOTCONN, ESHUTDOWN, EINTR, EISCONN, ECONNABORTED, errorcode --- line 329 def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] == ECONNABORTED: + self.handle_close() + return 0 else: raise return 0 --- line 340 def recv(self, buffer_size): try: data = self.socket.recv(buffer_size) if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return '' else: return data except socket.error, why: # winsock sometimes throws ENOTCONN - if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: + if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED]: self.handle_close() return '' else: raise ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Wed Jun 13 23:58:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 14:58:25 -0700 Subject: [Patches] [ python-Patches-1736101 ] asyncore should handle also ECONNABORTED in recv Message-ID: Patches item #1736101, was opened at 2007-06-12 23:10 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 Please note that this 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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore should handle also ECONNABORTED in recv Initial Comment: asyncore should handle also ECONNABORTED in recv in which case handle_close must be called. The two programs in attachment, an asyncore based echo-server and a simple client application terminating after having sent some data, shows how the server raises an ECONNABORTED exception. Note that the exception does not occur if server responds immediatly so I used a time.sleep(1) statement to let internal socket perform send() on the remote 'dead' peer. Having said that it's probable that ECONNABORTED should be handled also in send method. Hope this helps. ---------------------------------------------------------------------- >Comment By: billiejoex (billiejoex) Date: 2007-06-13 23:58 Message: Logged In: YES user_id=1357589 Originator: YES You're right, sorry. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-13 23:13 Message: Logged In: YES user_id=341410 Originator: NO Re-read the patch. In particular... @@ -333,9 +349,11 @@ except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] in (ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED): + self.handle_close() + return 0 That is added handling for all four potential errors in send. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-13 21:03 Message: Logged In: YES user_id=1357589 Originator: YES Hi, I've seen your patch but it seems to me that it doesn't include ECONNABORTED handling for send method. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-13 02:40 Message: Logged In: YES user_id=341410 Originator: NO Please see python.org/sf/1736190 for a patch that includes this particular bugfixe to asyncore, among others. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-12 23:13 Message: Logged In: YES user_id=1357589 Originator: YES client ====== import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 21)) s.send("sumthin") server ====== import asyncore, asynchat import socket import time class Handler(asynchat.async_chat): def __init__(self, server, sock, addr): asynchat.async_chat.__init__(self, sock) self.set_terminator("\n") self.data = "" self.respond("Hey there!\r\n") def respond(self, data): print "->" + data time.sleep(1) self.push(data) def collect_incoming_data(self, data): print "<-" + data self.data = self.data + data def found_terminator(self): self.respond(self.data) self.data = '' def handle_close(self): remote_ip, remote_port = self.socket.getpeername() print "%s:%s disconnected" %(remote_ip, remote_port) self.close() def handle_error(self): raise class Server(asyncore.dispatcher): def __init__(self, address): asyncore.dispatcher.__init__(self) self.create_socket(socket.AF_INET, socket.SOCK_STREAM) self.bind(address) self.listen(5) def handle_accept(self): conn, addr = self.accept() Handler(self, conn, addr) address = ('', 21) Server(address) print "server ready." asyncore.loop() proposed patch ============== --- line 55 - from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ - ENOTCONN, ESHUTDOWN, EINTR, EISCONN, errorcode + from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET, \ + ENOTCONN, ESHUTDOWN, EINTR, EISCONN, ECONNABORTED, errorcode --- line 329 def send(self, data): try: result = self.socket.send(data) return result except socket.error, why: if why[0] == EWOULDBLOCK: return 0 + elif why[0] == ECONNABORTED: + self.handle_close() + return 0 else: raise return 0 --- line 340 def recv(self, buffer_size): try: data = self.socket.recv(buffer_size) if not data: # a closed connection is indicated by signaling # a read condition, and having recv() return 0. self.handle_close() return '' else: return data except socket.error, why: # winsock sometimes throws ENOTCONN - if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]: + if why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN, ECONNABORTED]: self.handle_close() return '' else: raise ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1736101&group_id=5470 From noreply at sourceforge.net Thu Jun 14 07:10:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 13 Jun 2007 22:10:41 -0700 Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from tokanize.c. Message-ID: Patches item #1720390, was opened at 2007-05-16 17:23 Message generated for change (Comment added) made by ron_adam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470 Please note that this 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 Private: No Submitted By: Ron Adam (ron_adam) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove backslash escapes from tokanize.c. Initial Comment: This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only. A few strings needed changes in order to compile. Two in textwrap.py, and one in distutils/util.py. This does not include changes needed for tests to pass. I'll include those in a separate patch. ---------------------------------------------------------------------- >Comment By: Ron Adam (ron_adam) Date: 2007-06-14 00:10 Message: Logged In: YES user_id=1687923 Originator: YES Updated patch. The error that I had mentioned before has been fixed. Added changes to the tokanize_test output comparison file. It has random failures due to it using a random sample of other tests as sources to do round trip tests with. If those files have a problems in them, then this tests fails. Added a filename output line to the test so the problem file can be identified. Patch is against the py3k_struni branch, revision 55970 File Added: norawescape3.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-25 23:27 Message: Logged In: YES user_id=6380 Originator: NO Just FYI, I have downloaded this and will attempt to apply it some time next week. ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-05-19 21:15 Message: Logged In: YES user_id=1687923 Originator: YES Here's a more complete patch which modifies the following files... (in py3k_struni branch) M Python/ast.c M Parser/tokenizer.c M Lib/test/tokenize_tests.txt M Lib/tokenize.py The test still dosen't pass, but it fails in the same way as it did before these changes were made. I'll continue to look into this. I think it's more of a problem with the test it self and not a problem with the modules. Or it may be a bug in the struni branch that is yet to be fixed. The following alter one or two raw strings each replacing the outer most quotes with triple quotes in most cases. M Lib/sgmllib.py M Lib/markupbase.py M Lib/textwrap.py M Lib/distutils/util.py M Lib/cookielib.py M Lib/pydoc.py M Lib/doctest.py M Lib/xml/etree/ElementTree.py M Lib/HTMLParser.py File Added: norawescape2.diff ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-05-19 21:14 Message: Logged In: YES user_id=1687923 Originator: YES Here's a more complete patch which modifies the following files... (in py3k_struni branch) M Python/ast.c M Parser/tokenizer.c M Lib/test/tokenize_tests.txt M Lib/tokenize.py The test still dosen't pass, but it fails in the same way as it did before these changes were made. I'll continue to look into this. I think it's more of a problem with the test it self and not a problem with the modules. Or it may be a bug in the struni branch that is yet to be fixed. The following alter one or two raw strings each replacing the outer most quotes with triple quotes in most cases. M Lib/sgmllib.py M Lib/markupbase.py M Lib/textwrap.py M Lib/distutils/util.py M Lib/cookielib.py M Lib/pydoc.py M Lib/doctest.py M Lib/xml/etree/ElementTree.py M Lib/HTMLParser.py ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-05-16 17:31 Message: Logged In: YES user_id=1687923 Originator: YES Forgot to specify... This is against the py3k-struni branch, revision 55388. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470 From noreply at sourceforge.net Thu Jun 14 22:47:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 13:47:44 -0700 Subject: [Patches] [ python-Patches-1734014 ] PY_LLONG_MAX and so on Message-ID: Patches item #1734014, was opened at 2007-06-09 12:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734014&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: PY_LLONG_MAX and so on Initial Comment: Hello. Probably this patch is needed for building python on Windows now. Maybe does LLONG_MAX exist on VC7 or later? Even if so, I think this is better for type __int64. (At least, on VC6 build fails) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-14 22:47 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r55975 and r55976. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1734014&group_id=5470 From noreply at sourceforge.net Fri Jun 15 02:34:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 14 Jun 2007 17:34:19 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 06:46 Message generated for change (Comment added) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 Please note that this 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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-14 17:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 14:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 06:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Fri Jun 15 15:47:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 06:47:25 -0700 Subject: [Patches] [ python-Patches-1737832 ] EasyDialogs patch to remove aepack dependency Message-ID: Patches item #1737832, was opened at 2007-06-15 13: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=1737832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: EasyDialogs patch to remove aepack dependency Initial Comment: Patch for Python 2.5 that eliminates the aepack dependency from the EasyDialogs module, allowing aetools & co. to be removed without breaking EasyDialogs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1737832&group_id=5470 From noreply at sourceforge.net Fri Jun 15 18:30:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 09:30:23 -0700 Subject: [Patches] [ python-Patches-1720390 ] Remove backslash escapes from tokenize.c. Message-ID: Patches item #1720390, was opened at 2007-05-16 18:23 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470 Please note that this 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 Private: No Submitted By: Ron Adam (ron_adam) Assigned to: Guido van Rossum (gvanrossum) >Summary: Remove backslash escapes from tokenize.c. Initial Comment: This patch modifies tokanizer.c so that it does not skip the character after a backslash in determining the end of a string in raw strings only. A few strings needed changes in order to compile. Two in textwrap.py, and one in distutils/util.py. This does not include changes needed for tests to pass. I'll include those in a separate patch. ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-06-14 01:10 Message: Logged In: YES user_id=1687923 Originator: YES Updated patch. The error that I had mentioned before has been fixed. Added changes to the tokanize_test output comparison file. It has random failures due to it using a random sample of other tests as sources to do round trip tests with. If those files have a problems in them, then this tests fails. Added a filename output line to the test so the problem file can be identified. Patch is against the py3k_struni branch, revision 55970 File Added: norawescape3.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-05-26 00:27 Message: Logged In: YES user_id=6380 Originator: NO Just FYI, I have downloaded this and will attempt to apply it some time next week. ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-05-19 22:15 Message: Logged In: YES user_id=1687923 Originator: YES Here's a more complete patch which modifies the following files... (in py3k_struni branch) M Python/ast.c M Parser/tokenizer.c M Lib/test/tokenize_tests.txt M Lib/tokenize.py The test still dosen't pass, but it fails in the same way as it did before these changes were made. I'll continue to look into this. I think it's more of a problem with the test it self and not a problem with the modules. Or it may be a bug in the struni branch that is yet to be fixed. The following alter one or two raw strings each replacing the outer most quotes with triple quotes in most cases. M Lib/sgmllib.py M Lib/markupbase.py M Lib/textwrap.py M Lib/distutils/util.py M Lib/cookielib.py M Lib/pydoc.py M Lib/doctest.py M Lib/xml/etree/ElementTree.py M Lib/HTMLParser.py File Added: norawescape2.diff ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-05-19 22:14 Message: Logged In: YES user_id=1687923 Originator: YES Here's a more complete patch which modifies the following files... (in py3k_struni branch) M Python/ast.c M Parser/tokenizer.c M Lib/test/tokenize_tests.txt M Lib/tokenize.py The test still dosen't pass, but it fails in the same way as it did before these changes were made. I'll continue to look into this. I think it's more of a problem with the test it self and not a problem with the modules. Or it may be a bug in the struni branch that is yet to be fixed. The following alter one or two raw strings each replacing the outer most quotes with triple quotes in most cases. M Lib/sgmllib.py M Lib/markupbase.py M Lib/textwrap.py M Lib/distutils/util.py M Lib/cookielib.py M Lib/pydoc.py M Lib/doctest.py M Lib/xml/etree/ElementTree.py M Lib/HTMLParser.py ---------------------------------------------------------------------- Comment By: Ron Adam (ron_adam) Date: 2007-05-16 18:31 Message: Logged In: YES user_id=1687923 Originator: YES Forgot to specify... This is against the py3k-struni branch, revision 55388. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1720390&group_id=5470 From noreply at sourceforge.net Sat Jun 16 00:00:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 15:00:33 -0700 Subject: [Patches] [ python-Patches-1726451 ] ftplib and ProFTPD NLST 226 without 1xx response Message-ID: Patches item #1726451, was opened at 2007-05-27 17:06 Message generated for change (Comment added) made by billiejoex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kenneth Loafman (loafman) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib and ProFTPD NLST 226 without 1xx response Initial Comment: When ProFTPD and others do an NLST on an empty directory, they return a '226 Transfer Complete' without a 1xx response following (passive mode). They also may reset the connection, producing a '104, Connection reset by peer'. This patch corrects the 226 without 1xx response. Due to bug reports on ProFTPD indicating that the connection reset may be their issue, this patch does not address that problem. ---------------------------------------------------------------------- Comment By: billiejoex (billiejoex) Date: 2007-06-16 00:00 Message: Logged In: YES user_id=1357589 Originator: NO According to RFC959 the returning output of LIST and NLST commands should be sent over the data connection. Avoiding to open data connection and directly responding with "226 Transfer complete" when no transfer has occurred just because directory is empty is a wrong behaviour. The problem, if it really exists (are you really sure? It seems very strange to me), is up to ProFTPd, not ftplib. In case it really exists it is not within the realm of problems that should be dealt with by base ftplib since that it's a non RFC-compliant behaviour occurring with a particular product (ProFTPd). Best regards billiejoex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1726451&group_id=5470 From noreply at sourceforge.net Sat Jun 16 02:17:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 15 Jun 2007 17:17:58 -0700 Subject: [Patches] [ python-Patches-1738179 ] help() can't find right source file Message-ID: Patches item #1738179, was opened at 2007-06-15 17:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1738179&group_id=5470 Please note that this 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 Private: No Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: help() can't find right source file Initial Comment: The problem occurs when Python modules are precompiled with the the compileall module and the -d option to give a simpiler directory name (we use the application name because when we get error reports, where the application was installed is rarely important). Then introspection on a function in the inspect module gives a "non-existent" filename, i.e., func.func_code.co_filename gives the name for backtraces, not the actual filename. The right answer can be found by looking at sys.modules[func.__module__].__file__ and the attached patch does that. This patch is against Python2.4's Lib/inspect.py, but the bug is still present in SVN (Python 2.5.1+). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1738179&group_id=5470 From noreply at sourceforge.net Mon Jun 18 21:34:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 12:34:09 -0700 Subject: [Patches] [ python-Patches-1553427 ] locale.getdefaultlocale() bug when _locale is missing Message-ID: Patches item #1553427, was opened at 2006-09-06 14:00 Message generated for change (Comment added) made by gbrandl 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: Closed >Resolution: Fixed Priority: 5 Private: No 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 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-18 19:34 Message: Logged In: YES user_id=849994 Originator: NO Fixed in 2.5.1 according to the reporter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1553427&group_id=5470 From noreply at sourceforge.net Tue Jun 19 05:40:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 18 Jun 2007 20:40:37 -0700 Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to execute a zip file Message-ID: Patches item #1739468, was opened at 2007-06-19 03:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: andy-chu (andy-chu) Assigned to: Nobody/Anonymous (nobody) Summary: Add a -z interpreter flag to execute a zip file Initial Comment: The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules. I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function. With this small patch, you get rid of the need for extra files. At the bottom is a demo on Linux. On Windows, you can do a similar thing by making a file that is both a zip file and a batch file. The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter. I ran this by Guido and he seemed to think it was a fine idea. At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem. I have included the basic patch, but if you guys agree with this, I will add some tests and documentation. And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)? I think this may also help to fix a bug with eggs: http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name. andychu testdata$ ls __zipmain__.py foo.py foo.pyc foo.zip foo_exe.zip header.txt update_zip.sh # The main program you're going to run in "development mode" andychu testdata$ ./foo.py foo bar argv: ['./foo.py', 'foo', 'bar'] # Same program, packaged into a zip file andychu testdata$ ./foo_exe.zip foo bar argv: ['-c', 'foo', 'bar'] # Contents of the zip file andychu testdata$ unzip -l foo_exe.zip Archive: foo_exe.zip warning [foo_exe.zip]: 51 extra bytes at beginning or within zipfile (attempting to process anyway) Length Date Time Name -------- ---- ---- ---- 243 06-18-07 20:01 __zipmain__.py 301 06-18-07 19:58 foo.py -------- ------- 544 2 files # Demo script to build an executable zip file. andychu testdata$ cat header.txt #!/usr/local/google/clients/python/trunk/python -z andychu testdata$ cat update_zip.sh #!/bin/bash # Make a regular zip file. zip foo.zip foo.py __zipmain__.py # Add a shebang line to it. cat header.txt foo.zip > foo_exe.zip # Make it executable. chmod 750 foo_exe.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 From noreply at sourceforge.net Tue Jun 19 12:56:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 03:56:48 -0700 Subject: [Patches] [ python-Patches-1739648 ] zipfile.testzip() using progressive file reads Message-ID: Patches item #1739648, was opened at 2007-06-19 12:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739648&group_id=5470 Please note that this 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 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.testzip() using progressive file reads Initial Comment: testzip() still fails for big files. This patch implements reading small buffers. Also corrected main() where the return value of testzip() is ignored, hiding errors in zipfiles. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739648&group_id=5470 From noreply at sourceforge.net Tue Jun 19 13:21:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 04:21:07 -0700 Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to execute a zip file Message-ID: Patches item #1739468, was opened at 2007-06-19 13:40 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: andy-chu (andy-chu) >Assigned to: Nick Coghlan (ncoghlan) Summary: Add a -z interpreter flag to execute a zip file Initial Comment: The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules. I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function. With this small patch, you get rid of the need for extra files. At the bottom is a demo on Linux. On Windows, you can do a similar thing by making a file that is both a zip file and a batch file. The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter. I ran this by Guido and he seemed to think it was a fine idea. At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem. I have included the basic patch, but if you guys agree with this, I will add some tests and documentation. And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)? I think this may also help to fix a bug with eggs: http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name. andychu testdata$ ls __zipmain__.py foo.py foo.pyc foo.zip foo_exe.zip header.txt update_zip.sh # The main program you're going to run in "development mode" andychu testdata$ ./foo.py foo bar argv: ['./foo.py', 'foo', 'bar'] # Same program, packaged into a zip file andychu testdata$ ./foo_exe.zip foo bar argv: ['-c', 'foo', 'bar'] # Contents of the zip file andychu testdata$ unzip -l foo_exe.zip Archive: foo_exe.zip warning [foo_exe.zip]: 51 extra bytes at beginning or within zipfile (attempting to process anyway) Length Date Time Name -------- ---- ---- ---- 243 06-18-07 20:01 __zipmain__.py 301 06-18-07 19:58 foo.py -------- ------- 544 2 files # Demo script to build an executable zip file. andychu testdata$ cat header.txt #!/usr/local/google/clients/python/trunk/python -z andychu testdata$ cat update_zip.sh #!/bin/bash # Make a regular zip file. zip foo.zip foo.py __zipmain__.py # Add a shebang line to it. cat header.txt foo.zip > foo_exe.zip # Make it executable. chmod 750 foo_exe.zip ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-06-19 21:21 Message: Logged In: YES user_id=1038590 Originator: NO I like the general idea, but it should be possible to use runpy.run_module to get __name__ set correctly (as that is what happens when you execute a module from a zipfile with -m). Another advantage of using run_module is that it would allow runzip() to take a second argument (possibly defaulting to "__zipmain__") which would specify the module to be executed from the zipfile (the remaining 3 run_module arguments could also be passed in, and set appropriately from main.c). Adding the new function as runpy.run_zip() (instead of adding a new module) would also be good. For Windows, an alternative to making the zip file both a batch and a zip file would be to adopt a .pyz extension convention for these files - the file associations can then be set up to invoke the script appropriately with python -z (similar to the way that .pyw files are associated with pythonw instead of the standard python executable). That way the same file could be executed on both Linux (via an embedded shebang line) and on Windows (via filename association), as is the case with standard .py Python scripts. My final question is whether the change to sys.path should be reverted once the module execution is complete - my suspicion is that it should, but I need to look into it a bit more before giving a definite answer (for the command line flag case, this behaviour obviously doesn't matter - it is only significant if the Python method is invoked directly in the context of a larger program). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 From noreply at sourceforge.net Tue Jun 19 14:28:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 05:28:04 -0700 Subject: [Patches] [ python-Patches-1739696 ] Patch inspect.py for IronPython / Jython Compatibility Message-ID: Patches item #1739696, was opened at 2007-06-19 13:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739696&group_id=5470 Please note that this 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 Private: No Submitted By: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Patch inspect.py for IronPython / Jython Compatibility Initial Comment: Attached is a context patch against SVN head for the inspect module. It moves getting a reference to 'code.co_code' into the body of the loop responsible for inspecting anonymous (tuple) arguments. In IronPython, accessing 'co_code' raises a NotImplementedError - meaning that inspect.get_argspec is broken. This patch means that *except* for functions with anonymous tuple arguments, it will work again - whilst maintaining full compatibility with the previous behaviour. (A soimilar patch against Python 2.4.4 is in the IronPython Community Edition by Seo Sanghyeon.) Jython has a similar patch to overcome the same issue by the way. See http://jython.svn.sourceforge.net/viewvc/jython?view=rev&revision=3200 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739696&group_id=5470 From noreply at sourceforge.net Tue Jun 19 17:05:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:05:35 -0700 Subject: [Patches] [ python-Patches-1739789 ] Accelerate attr dict lookups Message-ID: Patches item #1739789, was opened at 2007-06-19 18:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 Please note that this 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 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: Accelerate attr dict lookups Initial Comment: * Added a PyDict_ExportKey feature to dictionaries, that creates a PyObject that holds the value of the item. * The hash table entries' top hash bit was abused to mean "is an exported entry", in which case the "value" refers to a PyDictItemObject, rather than an actual dictionary value. * PyDict_ExportKey can then be used to access certain dictionary keys with direct access/dereference, and not by dictionary lookups. * Slowdowns: All hash results are masked to remove the top bit, and the entries' hashes are also masked for comparison purposes. When the keys are found in the dict, the top hash bit is also consulted to see how to treat the value. * Speedups: The LOAD_GLOBAL/STORE_GLOBAL opcodes use direct access to read/write from the globals/builtins dicts, for the keys associated with the relevant co_names. * Results: * 40% speedup on the direct performance of LOAD_GLOBAL/STORE_GLOBAL instructions. * 5% speedup of pystones. * 5% speedup of a custom benchmark (attached, and based on http://www.webfast.com/~skip/python/fastpython.html) * 4.5% slowdown on the time it takes to run the regression tests. * Potential future speedups enabled by this patch: Ordinary attribute lookups can be converted to a type-check (ptr comparison) followed by direct access to the type's dict (or if an mro cache dict is added for each type, to that dict), rather than a dict lookup. Problems: * PyDict_Clear can now fail on a memory error. Before it could only fail on a PyDict_Check and was a void return value. Its signature may have to change to reflect the newly possible memory error (and the dict_check error that already existed). * I currently use co_names to determine which keys to export from the globals/builtins of the function object. co_names also includes attribute names, and not just globals, so I am wasting a bit of memory here, which may also affect caches/performance (the results may be better still). * I do not use a freelist for the PyDictItemObject's so their allocation/freeing may be slower than usual. * I no longer store a full 32-bit hash in the dict hashtable entries (only the low 31 bits, as I abuse the top bit), so the dict iterator that also yielded the hashes, used by set, now needs to recall the hash computation to yield those hashes. This makes the set-tests that count the number of hash calls fail (All other regression tests pass successfully). The "Vision": Replace virtually all dict lookups for attributes with exported key direct accesses by combining the above approaches with __slots__ or per-instance specialization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 From noreply at sourceforge.net Tue Jun 19 17:06:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 08:06:30 -0700 Subject: [Patches] [ python-Patches-1739789 ] Accelerate attr dict lookups Message-ID: Patches item #1739789, was opened at 2007-06-19 18:05 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 Please note that this 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 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: Accelerate attr dict lookups Initial Comment: * Added a PyDict_ExportKey feature to dictionaries, that creates a PyObject that holds the value of the item. * The hash table entries' top hash bit was abused to mean "is an exported entry", in which case the "value" refers to a PyDictItemObject, rather than an actual dictionary value. * PyDict_ExportKey can then be used to access certain dictionary keys with direct access/dereference, and not by dictionary lookups. * Slowdowns: All hash results are masked to remove the top bit, and the entries' hashes are also masked for comparison purposes. When the keys are found in the dict, the top hash bit is also consulted to see how to treat the value. * Speedups: The LOAD_GLOBAL/STORE_GLOBAL opcodes use direct access to read/write from the globals/builtins dicts, for the keys associated with the relevant co_names. * Results: * 40% speedup on the direct performance of LOAD_GLOBAL/STORE_GLOBAL instructions. * 5% speedup of pystones. * 5% speedup of a custom benchmark (attached, and based on http://www.webfast.com/~skip/python/fastpython.html) * 4.5% slowdown on the time it takes to run the regression tests. * Potential future speedups enabled by this patch: Ordinary attribute lookups can be converted to a type-check (ptr comparison) followed by direct access to the type's dict (or if an mro cache dict is added for each type, to that dict), rather than a dict lookup. Problems: * PyDict_Clear can now fail on a memory error. Before it could only fail on a PyDict_Check and was a void return value. Its signature may have to change to reflect the newly possible memory error (and the dict_check error that already existed). * I currently use co_names to determine which keys to export from the globals/builtins of the function object. co_names also includes attribute names, and not just globals, so I am wasting a bit of memory here, which may also affect caches/performance (the results may be better still). * I do not use a freelist for the PyDictItemObject's so their allocation/freeing may be slower than usual. * I no longer store a full 32-bit hash in the dict hashtable entries (only the low 31 bits, as I abuse the top bit), so the dict iterator that also yielded the hashes, used by set, now needs to recall the hash computation to yield those hashes. This makes the set-tests that count the number of hash calls fail (All other regression tests pass successfully). The "Vision": Replace virtually all dict lookups for attributes with exported key direct accesses by combining the above approaches with __slots__ or per-instance specialization. ---------------------------------------------------------------------- >Comment By: Eyal Lotem (peaker) Date: 2007-06-19 18:06 Message: Logged In: YES user_id=231480 Originator: YES File Added: words.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 From noreply at sourceforge.net Tue Jun 19 21:10:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 Jun 2007 12:10:46 -0700 Subject: [Patches] [ python-Patches-1739906 ] Add reduce to functools in 2.6 Message-ID: Patches item #1739906, was opened at 2007-06-19 21:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739906&group_id=5470 Please note that this 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 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Add reduce to functools in 2.6 Initial Comment: I'm proposing to add reduce to functools to make code forward compatible with 3.0 code. Since 2to3 has no fixer for reduce it's an easy way to make code run under 2.6 and 3.0 w/o a try/except ImportError block. Index: Lib/functools.py =================================================================== --- Lib/functools.py (revision 56041) +++ Lib/functools.py (working copy) @@ -8,6 +8,7 @@ # See C source code for _functools credits/copyright from _functools import partial +from __builtin__ import reduce # update_wrapper() and wraps() are tools to help write # wrapper functions that can handle naive introspection ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739906&group_id=5470 From noreply at sourceforge.net Wed Jun 20 18:05:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 09:05:36 -0700 Subject: [Patches] [ python-Patches-1739696 ] Patch inspect.py for IronPython / Jython Compatibility Message-ID: Patches item #1739696, was opened at 2007-06-19 08:28 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739696&group_id=5470 Please note that this 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 Private: No Submitted By: Mike Foord (mjfoord) >Assigned to: Collin Winter (collinwinter) Summary: Patch inspect.py for IronPython / Jython Compatibility Initial Comment: Attached is a context patch against SVN head for the inspect module. It moves getting a reference to 'code.co_code' into the body of the loop responsible for inspecting anonymous (tuple) arguments. In IronPython, accessing 'co_code' raises a NotImplementedError - meaning that inspect.get_argspec is broken. This patch means that *except* for functions with anonymous tuple arguments, it will work again - whilst maintaining full compatibility with the previous behaviour. (A soimilar patch against Python 2.4.4 is in the IronPython Community Edition by Seo Sanghyeon.) Jython has a similar patch to overcome the same issue by the way. See http://jython.svn.sourceforge.net/viewvc/jython?view=rev&revision=3200 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739696&group_id=5470 From noreply at sourceforge.net Wed Jun 20 20:12:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 11:12:59 -0700 Subject: [Patches] [ python-Patches-410547 ] os.statvfs support for Windows Message-ID: Patches item #410547, was opened at 2001-03-22 17:58 Message generated for change (Comment added) made by carstenkoch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 Please note that this 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: Closed Resolution: Rejected Priority: 3 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: os.statvfs support for Windows Initial Comment: This patch adds (partial) os.statvfs support for Windows. The FRSIZE, BLOCKS, BFREE, BAVAIL, and NAMEMAX fields are set. Remaining fields are set to zero, but should probably be set to None. </F> ---------------------------------------------------------------------- Comment By: Carsten Koch (carstenkoch) Date: 2007-06-20 20:12 Message: Logged In: YES user_id=1823318 Originator: NO Well, this has been rejected 6 years ago... Is there a portable way to get the available disk space by now? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 16:51 Message: Logged In: YES user_id=6380 Rejecting, since nobody seems interested in moving on this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-30 14:22 Message: Logged In: YES user_id=6380 Thanks for the investigation, Tim! Bouncing it back to Fredrik and lowered priority. I certainly don't want to spend a lot of time on it; I believe that the flamewar that started this was ill-advised anyway. Finding out free space is hard; too bad. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-30 06:13 Message: Logged In: YES user_id=31435 No, it did not go in. I asked for a doc patch first so I wouldn't have to pee away time trying to guess what it does. Now I've peed away the time, and I don't like it. Here's what it returns on my home desktop box (Win98SE, 20Gb drive): >>> os.statvfs("c:\\") # argument is very touchy (32768, 32768, 65526, 65526, 65526, 0, 0, 0, 0, 1024) >>> *Nothing* there makes sense, except for the last "max path" result. Even the "block size" is wrong (the FAT32 fs on this box uses 16Kb clusters, not 32Kb). Digging into the MS docs, """The GetDiskFreeSpace function returns incorrect values for volumes that are larger than 2 gigabytes""" and """Even on volumes that are smaller than 2 gigabytes, the values stored into *lpSectorsPerCluster, *lpNumberOfFreeClusters, and *lpTotalNumberOfClusters values may be incorrect""" under Win95, and, to judge from my desktop box, it appears useless under the latest flavor of Win98 too. The function the patch uses is obsolete, and a ...Ex version is recommended in its place, which """returns correct values for all volumes, including those that are greater than 2 gigabytes""" BUT, *that* function isn't available under the original Win95, only under Win95 OSR2 and later. In addition, that function only returns number of bytes total and free (as 64 bit unsigned ints), nothing about block size, # clusters, etc. (OTOH, total bytes is free is what people asked for! I don't recall anyone asking for a statvfs() clone) So bouncing back to you: how much time do you want me to devote to this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-29 19:28 Message: Logged In: YES user_id=6380 Tim, wasn't this supposed to go into 2.1b2? Did it? Can it go into 2.1final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-22 22:35 Message: Logged In: YES user_id=31435 /F, can you add a doc patch (for os.statvfs) that says enough so that a Windows user has some chance of guessing what this function returns? BTW, I have no problem w/ returning zeroes instead of Nones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=410547&group_id=5470 From noreply at sourceforge.net Thu Jun 21 02:54:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 Jun 2007 17:54:01 -0700 Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to execute a zip file Message-ID: Patches item #1739468, was opened at 2007-06-19 03:40 Message generated for change (Comment added) made by andy-chu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: andy-chu (andy-chu) Assigned to: Nick Coghlan (ncoghlan) Summary: Add a -z interpreter flag to execute a zip file Initial Comment: The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules. I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function. With this small patch, you get rid of the need for extra files. At the bottom is a demo on Linux. On Windows, you can do a similar thing by making a file that is both a zip file and a batch file. The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter. I ran this by Guido and he seemed to think it was a fine idea. At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem. I have included the basic patch, but if you guys agree with this, I will add some tests and documentation. And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)? I think this may also help to fix a bug with eggs: http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name. andychu testdata$ ls __zipmain__.py foo.py foo.pyc foo.zip foo_exe.zip header.txt update_zip.sh # The main program you're going to run in "development mode" andychu testdata$ ./foo.py foo bar argv: ['./foo.py', 'foo', 'bar'] # Same program, packaged into a zip file andychu testdata$ ./foo_exe.zip foo bar argv: ['-c', 'foo', 'bar'] # Contents of the zip file andychu testdata$ unzip -l foo_exe.zip Archive: foo_exe.zip warning [foo_exe.zip]: 51 extra bytes at beginning or within zipfile (attempting to process anyway) Length Date Time Name -------- ---- ---- ---- 243 06-18-07 20:01 __zipmain__.py 301 06-18-07 19:58 foo.py -------- ------- 544 2 files # Demo script to build an executable zip file. andychu testdata$ cat header.txt #!/usr/local/google/clients/python/trunk/python -z andychu testdata$ cat update_zip.sh #!/bin/bash # Make a regular zip file. zip foo.zip foo.py __zipmain__.py # Add a shebang line to it. cat header.txt foo.zip > foo_exe.zip # Make it executable. chmod 750 foo_exe.zip ---------------------------------------------------------------------- >Comment By: andy-chu (andy-chu) Date: 2007-06-21 00:54 Message: Logged In: YES user_id=1821575 Originator: YES Nick, you're right, I think it can use run_module and be in the runpy module. Let me make those changes and send you another patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-06-19 11:21 Message: Logged In: YES user_id=1038590 Originator: NO I like the general idea, but it should be possible to use runpy.run_module to get __name__ set correctly (as that is what happens when you execute a module from a zipfile with -m). Another advantage of using run_module is that it would allow runzip() to take a second argument (possibly defaulting to "__zipmain__") which would specify the module to be executed from the zipfile (the remaining 3 run_module arguments could also be passed in, and set appropriately from main.c). Adding the new function as runpy.run_zip() (instead of adding a new module) would also be good. For Windows, an alternative to making the zip file both a batch and a zip file would be to adopt a .pyz extension convention for these files - the file associations can then be set up to invoke the script appropriately with python -z (similar to the way that .pyw files are associated with pythonw instead of the standard python executable). That way the same file could be executed on both Linux (via an embedded shebang line) and on Windows (via filename association), as is the case with standard .py Python scripts. My final question is whether the change to sys.path should be reverted once the module execution is complete - my suspicion is that it should, but I need to look into it a bit more before giving a definite answer (for the command line flag case, this behaviour obviously doesn't matter - it is only significant if the Python method is invoked directly in the context of a larger program). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 From noreply at sourceforge.net Fri Jun 22 08:54:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 21 Jun 2007 23:54:03 -0700 Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs described in #1725899 Message-ID: Patches item #1741308, was opened at 2007-06-22 06: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=1741308&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Decimal.sqrt bugs described in #1725899 Initial Comment: This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt(); see bug report 1725899 for details of these. As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal; on my iBook G4 the speedup is between 20 and 25 times with the default precision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&group_id=5470 From noreply at sourceforge.net Fri Jun 22 09:09:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 00:09:55 -0700 Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs described in #1725899 Message-ID: Patches item #1741308, was opened at 2007-06-21 23:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Dickinson (marketdickinson) >Assigned to: Facundo Batista (facundobatista) Summary: Fix Decimal.sqrt bugs described in #1725899 Initial Comment: This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt(); see bug report 1725899 for details of these. As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal; on my iBook G4 the speedup is between 20 and 25 times with the default precision. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-22 00:09 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&group_id=5470 From noreply at sourceforge.net Fri Jun 22 14:29:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 Jun 2007 05:29:56 -0700 Subject: [Patches] [ python-Patches-1741308 ] Fix Decimal.sqrt bugs described in #1725899 Message-ID: Patches item #1741308, was opened at 2007-06-22 03:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Facundo Batista (facundobatista) Summary: Fix Decimal.sqrt bugs described in #1725899 Initial Comment: This patch fixes a number of (yet-to-be-confirmed-as-) bugs in Decimal.sqrt(); see bug report 1725899 for details of these. As a side benefit the modified version of Decimal.sqrt() runs significantly faster than the original, since it's based on integer arithmetic instead of carrying out Newton's method entirely in decimal; on my iBook G4 the speedup is between 20 and 25 times with the default precision. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-06-22 09:29 Message: Logged In: YES user_id=752496 Originator: NO Yes, I'll handle this and the mentioned bug. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-22 04:09 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1741308&group_id=5470 From noreply at sourceforge.net Sun Jun 24 22:17:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jun 2007 13:17:57 -0700 Subject: [Patches] [ python-Patches-1739789 ] Accelerate attr dict lookups Message-ID: Patches item #1739789, was opened at 2007-06-19 17:05 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 Please note that this 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 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: Accelerate attr dict lookups Initial Comment: * Added a PyDict_ExportKey feature to dictionaries, that creates a PyObject that holds the value of the item. * The hash table entries' top hash bit was abused to mean "is an exported entry", in which case the "value" refers to a PyDictItemObject, rather than an actual dictionary value. * PyDict_ExportKey can then be used to access certain dictionary keys with direct access/dereference, and not by dictionary lookups. * Slowdowns: All hash results are masked to remove the top bit, and the entries' hashes are also masked for comparison purposes. When the keys are found in the dict, the top hash bit is also consulted to see how to treat the value. * Speedups: The LOAD_GLOBAL/STORE_GLOBAL opcodes use direct access to read/write from the globals/builtins dicts, for the keys associated with the relevant co_names. * Results: * 40% speedup on the direct performance of LOAD_GLOBAL/STORE_GLOBAL instructions. * 5% speedup of pystones. * 5% speedup of a custom benchmark (attached, and based on http://www.webfast.com/~skip/python/fastpython.html) * 4.5% slowdown on the time it takes to run the regression tests. * Potential future speedups enabled by this patch: Ordinary attribute lookups can be converted to a type-check (ptr comparison) followed by direct access to the type's dict (or if an mro cache dict is added for each type, to that dict), rather than a dict lookup. Problems: * PyDict_Clear can now fail on a memory error. Before it could only fail on a PyDict_Check and was a void return value. Its signature may have to change to reflect the newly possible memory error (and the dict_check error that already existed). * I currently use co_names to determine which keys to export from the globals/builtins of the function object. co_names also includes attribute names, and not just globals, so I am wasting a bit of memory here, which may also affect caches/performance (the results may be better still). * I do not use a freelist for the PyDictItemObject's so their allocation/freeing may be slower than usual. * I no longer store a full 32-bit hash in the dict hashtable entries (only the low 31 bits, as I abuse the top bit), so the dict iterator that also yielded the hashes, used by set, now needs to recall the hash computation to yield those hashes. This makes the set-tests that count the number of hash calls fail (All other regression tests pass successfully). The "Vision": Replace virtually all dict lookups for attributes with exported key direct accesses by combining the above approaches with __slots__ or per-instance specialization. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2007-06-24 22:17 Message: Logged In: YES user_id=133955 Originator: NO Hi, I'm not in a position to review the patch, but a small design suggestion: if you need to abuse a bit in the hash structure, wouldn't it be simpler to abuse the least significant bit of the (PyObject*) pointer to the value stored in the dictentry? It seems to me that on today's architectures, pointers are at least 2-byte aligned (if not 4-byte). ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-19 17:06 Message: Logged In: YES user_id=231480 Originator: YES File Added: words.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 From noreply at sourceforge.net Mon Jun 25 08:24:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 24 Jun 2007 23:24:36 -0700 Subject: [Patches] [ python-Patches-1742669 ] "%d" format handling for long values Message-ID: Patches item #1742669, was opened at 2007-06-25 03:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1742669&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: "%d" format handling for long values Initial Comment: String formatting using %d doesn't handle well a long value when the object isn't a PyLong itself. That is: py> "%d" % 42L '42' py> "%d" % 10000000000000000000000000000000L '10000000000000000000000000000000' py> "%d" % 42.0 '42' py> "%d" % 10000000000000000000000000000000.0 Traceback (most recent call last): File "", line 1, in TypeError: int argument required Here it was shown with a float object, but any other object with a __long__ or __int__ method returning a PyLong fails (by example, the gmpy package). Currently PyString_Format, for "%d", checks whether the value *is* a PyLong and processes it, else tries to *convert* it to PyInt (and fails for large values). The attached patch first checks for a number; if it's a number but not PyInt nor PyLong, tries to convert to int; if it fails, tries to convert to long. The resulting value (either a PyInt or PyLong) is formatted the same way as before. If the original object was actually an int or long, it's handled the same way as before. The test ordering was chosen to only convert to long when necesary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1742669&group_id=5470 From noreply at sourceforge.net Mon Jun 25 21:10:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 Jun 2007 12:10:26 -0700 Subject: [Patches] [ python-Patches-1739789 ] Accelerate attr dict lookups Message-ID: Patches item #1739789, was opened at 2007-06-19 18:05 Message generated for change (Comment added) made by peaker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 Please note that this 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 Private: No Submitted By: Eyal Lotem (peaker) Assigned to: Nobody/Anonymous (nobody) Summary: Accelerate attr dict lookups Initial Comment: * Added a PyDict_ExportKey feature to dictionaries, that creates a PyObject that holds the value of the item. * The hash table entries' top hash bit was abused to mean "is an exported entry", in which case the "value" refers to a PyDictItemObject, rather than an actual dictionary value. * PyDict_ExportKey can then be used to access certain dictionary keys with direct access/dereference, and not by dictionary lookups. * Slowdowns: All hash results are masked to remove the top bit, and the entries' hashes are also masked for comparison purposes. When the keys are found in the dict, the top hash bit is also consulted to see how to treat the value. * Speedups: The LOAD_GLOBAL/STORE_GLOBAL opcodes use direct access to read/write from the globals/builtins dicts, for the keys associated with the relevant co_names. * Results: * 40% speedup on the direct performance of LOAD_GLOBAL/STORE_GLOBAL instructions. * 5% speedup of pystones. * 5% speedup of a custom benchmark (attached, and based on http://www.webfast.com/~skip/python/fastpython.html) * 4.5% slowdown on the time it takes to run the regression tests. * Potential future speedups enabled by this patch: Ordinary attribute lookups can be converted to a type-check (ptr comparison) followed by direct access to the type's dict (or if an mro cache dict is added for each type, to that dict), rather than a dict lookup. Problems: * PyDict_Clear can now fail on a memory error. Before it could only fail on a PyDict_Check and was a void return value. Its signature may have to change to reflect the newly possible memory error (and the dict_check error that already existed). * I currently use co_names to determine which keys to export from the globals/builtins of the function object. co_names also includes attribute names, and not just globals, so I am wasting a bit of memory here, which may also affect caches/performance (the results may be better still). * I do not use a freelist for the PyDictItemObject's so their allocation/freeing may be slower than usual. * I no longer store a full 32-bit hash in the dict hashtable entries (only the low 31 bits, as I abuse the top bit), so the dict iterator that also yielded the hashes, used by set, now needs to recall the hash computation to yield those hashes. This makes the set-tests that count the number of hash calls fail (All other regression tests pass successfully). The "Vision": Replace virtually all dict lookups for attributes with exported key direct accesses by combining the above approaches with __slots__ or per-instance specialization. ---------------------------------------------------------------------- >Comment By: Eyal Lotem (peaker) Date: 2007-06-25 22:10 Message: Logged In: YES user_id=231480 Originator: YES Thanks for the suggestion. I decided not to manipulate the pointer though, because it seems more dangerous, portability-wise. Also, I have discovered a small problem with the patch (curse the build system for not rebuilding properly when things change :-) but I see no use posting it and continuing work on this patch, as it seems to generate so little interest. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2007-06-24 23:17 Message: Logged In: YES user_id=133955 Originator: NO Hi, I'm not in a position to review the patch, but a small design suggestion: if you need to abuse a bit in the hash structure, wouldn't it be simpler to abuse the least significant bit of the (PyObject*) pointer to the value stored in the dictentry? It seems to me that on today's architectures, pointers are at least 2-byte aligned (if not 4-byte). ---------------------------------------------------------------------- Comment By: Eyal Lotem (peaker) Date: 2007-06-19 18:06 Message: Logged In: YES user_id=231480 Originator: YES File Added: words.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739789&group_id=5470 From noreply at sourceforge.net Wed Jun 27 07:35:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 Jun 2007 22:35:24 -0700 Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to execute a zip file Message-ID: Patches item #1739468, was opened at 2007-06-19 03:40 Message generated for change (Comment added) made by andy-chu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: andy-chu (andy-chu) Assigned to: Nick Coghlan (ncoghlan) Summary: Add a -z interpreter flag to execute a zip file Initial Comment: The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules. I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function. With this small patch, you get rid of the need for extra files. At the bottom is a demo on Linux. On Windows, you can do a similar thing by making a file that is both a zip file and a batch file. The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter. I ran this by Guido and he seemed to think it was a fine idea. At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem. I have included the basic patch, but if you guys agree with this, I will add some tests and documentation. And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)? I think this may also help to fix a bug with eggs: http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name. andychu testdata$ ls __zipmain__.py foo.py foo.pyc foo.zip foo_exe.zip header.txt update_zip.sh # The main program you're going to run in "development mode" andychu testdata$ ./foo.py foo bar argv: ['./foo.py', 'foo', 'bar'] # Same program, packaged into a zip file andychu testdata$ ./foo_exe.zip foo bar argv: ['-c', 'foo', 'bar'] # Contents of the zip file andychu testdata$ unzip -l foo_exe.zip Archive: foo_exe.zip warning [foo_exe.zip]: 51 extra bytes at beginning or within zipfile (attempting to process anyway) Length Date Time Name -------- ---- ---- ---- 243 06-18-07 20:01 __zipmain__.py 301 06-18-07 19:58 foo.py -------- ------- 544 2 files # Demo script to build an executable zip file. andychu testdata$ cat header.txt #!/usr/local/google/clients/python/trunk/python -z andychu testdata$ cat update_zip.sh #!/bin/bash # Make a regular zip file. zip foo.zip foo.py __zipmain__.py # Add a shebang line to it. cat header.txt foo.zip > foo_exe.zip # Make it executable. chmod 750 foo_exe.zip ---------------------------------------------------------------------- >Comment By: andy-chu (andy-chu) Date: 2007-06-27 05:35 Message: Logged In: YES user_id=1821575 Originator: YES Nick, I've updated the code to use a new runpy.run_zip function, which calls run_module. This does make it a bit cleaner. Let me know what you think. If the code is good I'll write some tests and documentation. Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that seems to be what the -m flag uses. It seems like it might make sense to have sys.argv[0] be the zip file, if it is really a first class executable. And I think a script to build one of these files would be appropriate, which I can add. You could pass it the main module and main function, and it would generate a __zipmain__ stub and add it to the zip file. And it is a good idea if the file is cross platform, so a .pyz extension would work. Sorry the delayed response, I was a bit busy at work this week... but I'll respond sooner this time. : ) Example: andychu trunk$ testdata/foo_exe.zip foo bar __name__: __main__ argv: ['-c', 'foo', 'bar'] andychu trunk$ echo $? 3 File Added: runzip7.diff ---------------------------------------------------------------------- Comment By: andy-chu (andy-chu) Date: 2007-06-21 00:54 Message: Logged In: YES user_id=1821575 Originator: YES Nick, you're right, I think it can use run_module and be in the runpy module. Let me make those changes and send you another patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-06-19 11:21 Message: Logged In: YES user_id=1038590 Originator: NO I like the general idea, but it should be possible to use runpy.run_module to get __name__ set correctly (as that is what happens when you execute a module from a zipfile with -m). Another advantage of using run_module is that it would allow runzip() to take a second argument (possibly defaulting to "__zipmain__") which would specify the module to be executed from the zipfile (the remaining 3 run_module arguments could also be passed in, and set appropriately from main.c). Adding the new function as runpy.run_zip() (instead of adding a new module) would also be good. For Windows, an alternative to making the zip file both a batch and a zip file would be to adopt a .pyz extension convention for these files - the file associations can then be set up to invoke the script appropriately with python -z (similar to the way that .pyw files are associated with pythonw instead of the standard python executable). That way the same file could be executed on both Linux (via an embedded shebang line) and on Windows (via filename association), as is the case with standard .py Python scripts. My final question is whether the change to sys.path should be reverted once the module execution is complete - my suspicion is that it should, but I need to look into it a bit more before giving a definite answer (for the command line flag case, this behaviour obviously doesn't matter - it is only significant if the Python method is invoked directly in the context of a larger program). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 From noreply at sourceforge.net Wed Jun 27 20:08:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 11:08:03 -0700 Subject: [Patches] [ python-Patches-1744382 ] Read Write lock Message-ID: Patches item #1744382, was opened at 2007-06-27 20:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yaakov Nemoy (loupgaroublond) Assigned to: Nobody/Anonymous (nobody) Summary: Read Write lock Initial Comment: This is a Lock for handling both multiple readers and a single or multiple writers. It allows any number of readers to acquire a 'lock' via a modified semaphore. It also allows any number of writers to try to acquire a lock, which signals the lock to block new readers from acquiring, until the writers have had a chance to do their business. Through a simple lock, multiple writers can wait in line, although only one writer can actually write at a time. It also lets the developer use the 'with' statement, via methods that return contextmanagers. I actually had a couple of unimplemented ideas. A) Writers can specify a deadline (or even use a default) such that after the deadline passes, the lock can use a callback to rollback/kill/pause readers, so that the writer doesn't wait an eternity. B) Allowing the semaphore to have an upper limit of allowed readers (or anythings), Since I don't need it, i never programmed it, but it should be fairly trivial to implement if there is any demand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470 From noreply at sourceforge.net Wed Jun 27 20:44:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 11:44:32 -0700 Subject: [Patches] [ python-Patches-1744398 ] Improve exception pickling support Message-ID: Patches item #1744398, was opened at 2007-06-27 11: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=1744398&group_id=5470 Please note that this 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 Private: No Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: Improve exception pickling support Initial Comment: Due to various issues with how pickle works and new-style classes, pickling exception objects has been somewhat unreliable since Python 2.5. See comments in patch #1692335 for more detail. Attached is a patch that seems to improve pickling exceptions to support various different types of subclasses. It has some limitations (exceptions that use __slots__, doesn't fully support SyntaxError, UnicodeError, SystemExit, or WindowsError). However, it is an improvement for my situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744398&group_id=5470 From noreply at sourceforge.net Wed Jun 27 20:45:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 11:45:42 -0700 Subject: [Patches] [ python-Patches-1692335 ] Move initial args assignment to BaseException.__new__ Message-ID: Patches item #1692335, was opened at 2007-04-01 06:46 Message generated for change (Comment added) made by ehuss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 Please note that this 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 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Move initial args assignment to BaseException.__new__ Initial Comment: Pickling exceptions fails when an Exception class requires an argument in the constructor, but doesn't call its base class' constructor. See this mail for details: http://mail.python.org/pipermail/python-dev/2007-April/072416.html This patch simply moves initial args assignment to BaseException.__new__. This should fix most of the problems, because it is very unlikely that an exception overwrites the __new__ method; exceptions used to be old style classes, which don't support the __new__ special method. The args attribute is still overwritten in all the __init__ methods, so there shouldn't be any backward compatibility problems. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-27 11:45 Message: Logged In: YES user_id=393416 Originator: NO Added patch #1744398 as an alternate solution. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2007-06-14 17:34 Message: Logged In: YES user_id=393416 Originator: NO I have stumbled across another scenario where unpickling fails. If your exception takes arguments, but you call Exception.__init__ with a different number of arguments, it will fail. As in: class D(Exception): def __init__(self, foo): self.foo = foo Exception.__init__(self) ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 14:50 Message: Logged In: YES user_id=1326842 Originator: YES I'm attaching a test that Eric Huss sent in private mail. The test fails, because old exception pickles don't have args for the reconstructor, but their __init__() gets called anyway because they are new style classes now. The problem is in cPickle.InstanceNew() and pickle.Unpickler._instantiate(). Those methods behave differently depending on the type of the object instantiated; they avoid the __init__() call when type is an old style class. There is nothing that can be done in the exception classes to fix this issue; the fix would need to be in the pickle and cPickle module. File Added: test_exception_pickle.py ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-01 06:47 Message: Logged In: YES user_id=1326842 Originator: YES File Added: exc_args_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1692335&group_id=5470 From noreply at sourceforge.net Wed Jun 27 22:37:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 13:37:52 -0700 Subject: [Patches] [ python-Patches-1744456 ] Patch for feat. 713877 Expose callbackAPI in readline module Message-ID: Patches item #1744456, was opened at 2007-06-27 22:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744456&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: strank (strank) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for feat. 713877 Expose callbackAPI in readline module Initial Comment: Expose the callback API of GNU readline. Patch contains changes to readline.c and libreadline.tex, I did not find a unit-test for readline so there are no tests. One of the readline functions (callback_read_char) can potentially call abort(). This can happen on the interactive prompt, but I think that this is not a problem, since using this API from the interactive prompt (which itself uses it) does not make sense anyway. cheers, stefan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744456&group_id=5470 From noreply at sourceforge.net Thu Jun 28 07:17:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 27 Jun 2007 22:17:50 -0700 Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to execute a zip file Message-ID: Patches item #1739468, was opened at 2007-06-19 03:40 Message generated for change (Comment added) made by andy-chu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: andy-chu (andy-chu) Assigned to: Nick Coghlan (ncoghlan) Summary: Add a -z interpreter flag to execute a zip file Initial Comment: The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules. I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function. With this small patch, you get rid of the need for extra files. At the bottom is a demo on Linux. On Windows, you can do a similar thing by making a file that is both a zip file and a batch file. The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter. I ran this by Guido and he seemed to think it was a fine idea. At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem. I have included the basic patch, but if you guys agree with this, I will add some tests and documentation. And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)? I think this may also help to fix a bug with eggs: http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name. andychu testdata$ ls __zipmain__.py foo.py foo.pyc foo.zip foo_exe.zip header.txt update_zip.sh # The main program you're going to run in "development mode" andychu testdata$ ./foo.py foo bar argv: ['./foo.py', 'foo', 'bar'] # Same program, packaged into a zip file andychu testdata$ ./foo_exe.zip foo bar argv: ['-c', 'foo', 'bar'] # Contents of the zip file andychu testdata$ unzip -l foo_exe.zip Archive: foo_exe.zip warning [foo_exe.zip]: 51 extra bytes at beginning or within zipfile (attempting to process anyway) Length Date Time Name -------- ---- ---- ---- 243 06-18-07 20:01 __zipmain__.py 301 06-18-07 19:58 foo.py -------- ------- 544 2 files # Demo script to build an executable zip file. andychu testdata$ cat header.txt #!/usr/local/google/clients/python/trunk/python -z andychu testdata$ cat update_zip.sh #!/bin/bash # Make a regular zip file. zip foo.zip foo.py __zipmain__.py # Add a shebang line to it. cat header.txt foo.zip > foo_exe.zip # Make it executable. chmod 750 foo_exe.zip ---------------------------------------------------------------------- >Comment By: andy-chu (andy-chu) Date: 2007-06-28 05:17 Message: Logged In: YES user_id=1821575 Originator: YES Here is a script that documents how to make such files. I think the important part is just documenting the format. Then people can write whatever tools they need around it. Many people could get by with this simple tool, but others might want something more elaborate. Demo: andychu testprog$ find . ./__init__.py ./package1 ./package1/__init__.py ./package1/foo.py ./package1/lib.py ./package1/__init__.pyc ./package1/lib.pyc ./package1/foo.pyc andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a zip,pyz,unix -z foo.zip -p package1 -m foo -y /usr/local/google/clients/python/trunk/python Added ./__init__.py to foo.zip Added ./package1/__init__.py to foo.zip Added ./package1/foo.py to foo.zip Added ./package1/lib.py to foo.zip Added __zipmain__.py to foo.zip Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip. chmod foo.zip 0700 andychu testprog$ ./foo.zip lib module here argv: ['-c'] andychu testprog$ echo $? 3 File Added: makepyz.py ---------------------------------------------------------------------- Comment By: andy-chu (andy-chu) Date: 2007-06-27 05:35 Message: Logged In: YES user_id=1821575 Originator: YES Nick, I've updated the code to use a new runpy.run_zip function, which calls run_module. This does make it a bit cleaner. Let me know what you think. If the code is good I'll write some tests and documentation. Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that seems to be what the -m flag uses. It seems like it might make sense to have sys.argv[0] be the zip file, if it is really a first class executable. And I think a script to build one of these files would be appropriate, which I can add. You could pass it the main module and main function, and it would generate a __zipmain__ stub and add it to the zip file. And it is a good idea if the file is cross platform, so a .pyz extension would work. Sorry the delayed response, I was a bit busy at work this week... but I'll respond sooner this time. : ) Example: andychu trunk$ testdata/foo_exe.zip foo bar __name__: __main__ argv: ['-c', 'foo', 'bar'] andychu trunk$ echo $? 3 File Added: runzip7.diff ---------------------------------------------------------------------- Comment By: andy-chu (andy-chu) Date: 2007-06-21 00:54 Message: Logged In: YES user_id=1821575 Originator: YES Nick, you're right, I think it can use run_module and be in the runpy module. Let me make those changes and send you another patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-06-19 11:21 Message: Logged In: YES user_id=1038590 Originator: NO I like the general idea, but it should be possible to use runpy.run_module to get __name__ set correctly (as that is what happens when you execute a module from a zipfile with -m). Another advantage of using run_module is that it would allow runzip() to take a second argument (possibly defaulting to "__zipmain__") which would specify the module to be executed from the zipfile (the remaining 3 run_module arguments could also be passed in, and set appropriately from main.c). Adding the new function as runpy.run_zip() (instead of adding a new module) would also be good. For Windows, an alternative to making the zip file both a batch and a zip file would be to adopt a .pyz extension convention for these files - the file associations can then be set up to invoke the script appropriately with python -z (similar to the way that .pyw files are associated with pythonw instead of the standard python executable). That way the same file could be executed on both Linux (via an embedded shebang line) and on Windows (via filename association), as is the case with standard .py Python scripts. My final question is whether the change to sys.path should be reverted once the module execution is complete - my suspicion is that it should, but I need to look into it a bit more before giving a definite answer (for the command line flag case, this behaviour obviously doesn't matter - it is only significant if the Python method is invoked directly in the context of a larger program). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 From jtkx at russell96.karoo.co.uk Thu Jun 28 13:56:12 2007 From: jtkx at russell96.karoo.co.uk (Spence) Date: Thu, 28 Jun 2007 13:56:12 +0200 Subject: [Patches] We may have wasted the money that we bought all this Tamiflu for. Message-ID: <4683A1DC.8010102@gardencitymi.org> SREA Continues To Rocket, UP Another 29% By Close! Score One Inc. (SREA) $0.40 UP 29% The watchers are right, SREA keeps climbing. The Market Makers are raking it in. Act fast and you can too. Look at the numbers and get on SREA first thing Thursday! He also founded an environmentally-friendly online retailer called BetterLifeGoods. When it is injected properly, it strengthens the lower esophagus, helping prevent stomach acid from entering it and causing pain. We need to ban these drugs; we need to outlaw them. Last month, the FDA's credibility plunged with a decision to stall over-the-counter sale of the morning-after pill. And the person footing the bill is, of course, Joe Public. com, and books and interviews are published at www. Somebody's got to foot the bill. Keep on buying those personal care products, coating your hair in cancer-causing ingredients, coloring your hair with cancer-causing solvents. From eyy at tm.net.my Thu Jun 28 14:00:21 2007 From: eyy at tm.net.my (downstream) Date: Thu, 28 Jun 2007 14:00:21 +0200 Subject: [Patches] text_VVSJNIZ.pdf Message-ID: <4683A2D5.7030306@nifty.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: text_VVSJNIZ.pdf Type: application/pdf Size: 17518 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20070628/d00c5b9e/attachment.pdf From noreply at sourceforge.net Thu Jun 28 17:08:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 08:08:50 -0700 Subject: [Patches] [ python-Patches-1492704 ] distinct error type from shutil.move() Message-ID: Patches item #1492704, was opened at 2006-05-22 03:08 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470 Please note that this 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 Private: No Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Anthony Baxter (anthonybaxter) Summary: distinct error type from shutil.move() Initial Comment: I need to call shutil.move() and be able to tell the difference between an error such as access denied and an error due to the two arguments being the same file. --- old-dw/src/Lib/shutil.py 2006-05-22 00:06:02.000000000 -0300 +++ new-dw/src/Lib/shutil.py 2006-05-22 00:06:02.000000000 -0300 @@ -16,6 +16,9 @@ class Error(exceptions.EnvironmentError): pass +class SameFileError(Error): + pass + def copyfileobj(fsrc, fdst, length=16*1024): """copy data from file-like object fsrc to file-like object fdst""" while 1: @@ -39,7 +42,7 @@ def copyfile(src, dst): """Copy data from src to dst""" if _samefile(src, dst): - raise Error, "`%s` and `%s` are the same file" % (src, dst) + raise SameFileError, "`%s` and `%s` are the same file" % (src, dst) fsrc = None fdst = None ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2007-06-28 15:08 Message: Logged In: YES user_id=52562 Originator: YES Dear Pythonistas: please apply this patch. There is no reason not to, and it enables programmers to use shutil more cleanly. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2006-07-06 22:55 Message: Logged In: YES user_id=52562 I'm not sure how to draw attention to my patch, so I will try assigning it to anthonybaxter. That ought to get attention. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2006-07-06 22:53 Message: Logged In: YES user_id=52562 Please apply. This patch is completely backwards-compatible and makes possible some uses of shutil.move(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470 From noreply at sourceforge.net Thu Jun 28 18:09:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 Jun 2007 09:09:09 -0700 Subject: [Patches] [ python-Patches-1735030 ] Fix selectmodule.c compilation on GNU/Hurd Message-ID: Patches item #1735030, was opened at 2007-06-11 16:06 Message generated for change (Comment added) made by mbanck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Banck (mbanck) Assigned to: Nobody/Anonymous (nobody) Summary: Fix selectmodule.c compilation on GNU/Hurd Initial Comment: This patch (by Wouter van Heyst) fixes compilation of python2.5 on the Hurd (and other systems?) It fixes the following build error: gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/build/buildd/python2.5-2.5/./Include -I../Include -I. -I/build/buildd/python2.5-2.5/Include -I/build/buildd/python2.5-2.5/build-static -c /build/buildd/python2.5-2.5/Modules/selectmodule.c -o build/temp.gnu-0.3-i686-AT386-2.5/build/buildd/python2.5-2.5/Modules/selectmodule.o /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'select_poll' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:676: error: 'poll_doc' undeclared here (not in a function) /build/buildd/python2.5-2.5/Modules/selectmodule.c: In function 'initselect': /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: 'poll_Type' undeclared (first use in this function) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: (Each undeclared identifier is reported only once /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: for each function it appears in.) /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: error: request for member 'ob_type' in something not a structure or union /build/buildd/python2.5-2.5/Modules/selectmodule.c:709: warning: statement with no effect We hope this does not break other platforms, does this look OK? ---------------------------------------------------------------------- >Comment By: Michael Banck (mbanck) Date: 2007-06-28 18:09 Message: Logged In: YES user_id=196016 Originator: YES Hrm, upon further analysis, it looks likely that poll() really is not conforming to POSIX on GNU/Hurd and should get fixed, rather than HAVE_BROKEN_POLL code be changed. I have submitted this upstream to the Hurd developers, the patch should not be applied in the meantime (and might be obsolete). ---------------------------------------------------------------------- Comment By: Michael Banck (mbanck) Date: 2007-06-12 14:55 Message: Logged In: YES user_id=196016 Originator: YES Yes, python2.5 builds fine otherwise (at least the Debian package, I am not sure whether we applied local changes earlier). This HAVE_BROKEN_POLL issue was the only regression from python2.4 as far as the Debian GNU/Hurd port was concerned. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-12 04:54 Message: Logged In: YES user_id=33168 Originator: NO Is this only change required for Hurd? I'm not sure, but HAVE_BROKEN_POLL might have a specific meaning on OS X. So there might be a problem with this patch. I'd need to look at the whole file to verify. I'll try to remember to do that later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1735030&group_id=5470 From noreply at sourceforge.net Fri Jun 29 16:12:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 07:12:00 -0700 Subject: [Patches] [ python-Patches-1713041 ] fix for 1712742: corrects pprint's handling of 'depth' Message-ID: Patches item #1713041, was opened at 2007-05-04 15:13 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 Please note that this 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 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Neal Norwitz (nnorwitz) Summary: fix for 1712742: corrects pprint's handling of 'depth' Initial Comment: The patch is really simple. Just change the way "maxlevels" is checked. I couldn't find a way to have a test case for this bug. ---------------------------------------------------------------------- >Comment By: Raghuram Devarakonda (draghuram) Date: 2007-06-29 10:12 Message: Logged In: YES user_id=984087 Originator: YES Neal, can you please apply the patch? - Thanks. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-06-01 10:03 Message: Logged In: YES user_id=374783 Originator: NO Neal: sorry, I understood pprint.patch was the "current", valid patch, and the object of the most recent discussion. This is the one I was referring to. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 02:48 Message: Logged In: YES user_id=33168 Originator: NO Rodrigo, which patch are you giving +1? Sorry Raghu, I'm getting behind. :-( I'll try to take a look at this. If everything is consistent (docs, code, and tests) and has sane semantics, there shouldn't be anything else necessary. I just need to get the time to apply. Or someone else with commit privileges could apply this as well. If I don't get to this within a week or so, feel free to ping me via mail. ---------------------------------------------------------------------- Comment By: Rodrigo Bernardo Pimentel (errebepe) Date: 2007-05-30 23:06 Message: Logged In: YES user_id=374783 Originator: NO +1 on the patch (test, code and doc). In particular, if depth == 0 is not allowed, I think the patched behaviour is the expected one, so this is actually a bug fix rather than a change in the module's semantic. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-18 17:16 Message: Logged In: YES user_id=984087 Originator: YES Neal, is there anything else you want me to do for the patch? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 11:09 Message: Logged In: YES user_id=984087 Originator: YES josm, please feel free to go to python-dev if you think community input is required. I personally don't think that it is warranted. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-13 08:14 Message: Logged In: YES user_id=1776568 Originator: NO What is intuitive is a matter of taste. Some people like to count from zero, like many programmers do. ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-13 07:56 Message: Logged In: YES user_id=984087 Originator: YES josm, merely changing (fixing) the handling of "depth" parameter is not a spec change. The patch makes pprint behave in a way that is intuitive from the meaning of "depth". ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-12 10:09 Message: Logged In: YES user_id=1776568 Originator: NO Yes, the doc seems to be wrong, and I agree with you changing wrong doc is always right thing to do, but this patch changed the way how pprint handles 'depth'. I think I can call this as 'a spec change'. changing some existent module's behavior is something that needs to be done carefully. Don't we need a consensus among community? No one cares so much how pprint works? could be ... ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 17:41 Message: Logged In: YES user_id=984087 Originator: YES josm> I just thought if changing the doc itself would cause josm> some problem, we have to fix the code to work the way josm> the doc says. Not if the doc is wrong. josm> Don't we have to get someone's approval to change the josm> spec? We are not changing the spec here. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 17:37 Message: Logged In: YES user_id=1776568 Originator: NO That test case was for pp2.diff. I just thought if changing the doc itself would cause some problem, we have to fix the code to work the way the doc says. Don't we have to get someone's approval to change the spec? ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 10:13 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint.patch ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-10 10:13 Message: Logged In: YES user_id=984087 Originator: YES josm, I don't think there is need for a new test case. The one in the patch correctly tests the code change. As Neal pointed out, the doc is wrong to begin with. I updated the patch with the doc change. Note that I replaced the current example with a very simple one. I believe the current one is overly complicated for this purpose. Comments are welcome, of course. ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-10 07:56 Message: Logged In: YES user_id=1776568 Originator: NO I agree. The code and the doc should be consistent. New test would be Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55223) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,27 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), repr(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), repr(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), repr(nested_list)) + + result_tuple = {'lv1': '(...)', + 'lv2': '(1, (...))'} + result_dict = {'lv1': '{...}', + 'lv2': '{1: {...}}'} + result_list = {'lv1': '[...]', + 'lv2': '[1, [...]]'} + for i in [1, 2]: + key = 'lv' + `i` + self.assertEqual(pprint.pformat(nested_tuple, depth=i), result_tuple[key]) + self.assertEqual(pprint.pformat(nested_dict, depth=i), result_dict[key]) + self.assertEqual(pprint.pformat(nested_list, depth=i), result_list[key]) + class DottedPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-10 02:18 Message: Logged In: YES user_id=33168 Originator: NO Yes, that's the example I'm referring to. In the doc, it shows 5 numbers and one ... for 6. Without your patch it shows 7 numbers and with your patch it shows 6 numbers. So even with your patch the doc and code don't agree (they are off by one, rather than 2 as is currently the case). ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-09 10:44 Message: Logged In: YES user_id=984087 Originator: YES Hi Neal, I assume you are referring to the example >>> import parser >>> tup = parser.ast2tuple( ... parser.suite(open('pprint.py').read()))[1][1][1] >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint(tup) in the document. Is that correct? I ran this example with and without my patch. Without the update, the example printed 7 levels which is one level too deep. With the patch, it printed 6 levels, which seems correct to me. # without patch. prints 7 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (306, (...)))))))) # with patch. prints 6 levels. $ ../python/python testdoc.py (268, (269, (326, (303, (304, (305, (...))))))) I am attaching the file testdoc.py which contains the doc example. I just wanted to confirm that this is what you are referring to. File Added: testdoc.py ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-09 02:56 Message: Logged In: YES user_id=33168 Originator: NO I notice in the doc an example which doesn't work with this patch. It still prints one level too deep. The doc seems correct to me, but I don't have strong feelings any way. The attached patch makes the doc example work as expected. The doc should really be updated with an example more like: >>> pp = pprint.PrettyPrinter(depth=6) >>> pp.pprint((1, (2, (3, (4, (5, (6, 7))))))) (1, (2, (3, (4, (5, (...)))))) >>> pp = pprint.PrettyPrinter(depth=1) >>> pp.pprint(1) 1 >>> pp.pprint([1]) [...] The updated patch causes the new tests to fail. Could you update the test/code/doc to all be consistent? File Added: pp2.diff ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-07 10:49 Message: Logged In: YES user_id=984087 Originator: YES josm, thanks for the test case. I incorporated it into the patch. BTW, I changed "str" to "repr" as I think "repr" is closer to what pformat does. File Added: pprint.patch ---------------------------------------------------------------------- Comment By: jos (josm) Date: 2007-05-05 05:02 Message: Logged In: YES user_id=1776568 Originator: NO Your patch looks good and worked fine. Wouldn't it be nice to add a test case for this problem to test_pprint.py? The following is just draft patch to add the test case. Index: Lib/test/test_pprint.py =================================================================== --- Lib/test/test_pprint.py (revision 55144) +++ Lib/test/test_pprint.py (working copy) @@ -195,7 +195,22 @@ others.should.not.be: like.this}""" self.assertEqual(DottedPrettyPrinter().pformat(o), exp) + def test_depth(self): + nested_tuple = (1, (2, (3, (4, (5, 6))))) + nested_dict = {1: {2: {3: {4: {5: {6: 6}}}}}} + nested_list = [1, [2, [3, [4, [5, [6, []]]]]]] + self.assertEqual(pprint.pformat(nested_tuple), str(nested_tuple)) + self.assertEqual(pprint.pformat(nested_dict), str(nested_dict)) + self.assertEqual(pprint.pformat(nested_list), str(nested_list)) + + lv1_tuple = '(1, (...))' + lv1_dict = '{1: {...}}' + lv1_list = '[1, [...]]' + self.assertEqual(pprint.pformat(nested_tuple, depth=1), lv1_tuple) + self.assertEqual(pprint.pformat(nested_dict, depth=1), lv1_dict) + self.assertEqual(pprint.pformat(nested_list, depth=1), lv1_list) + ---------------------------------------------------------------------- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-05-04 15:15 Message: Logged In: YES user_id=984087 Originator: YES File Added: pprint_test.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1713041&group_id=5470 From noreply at sourceforge.net Fri Jun 29 16:40:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 Jun 2007 07:40:06 -0700 Subject: [Patches] [ python-Patches-1739468 ] Add a -z interpreter flag to execute a zip file Message-ID: Patches item #1739468, was opened at 2007-06-19 13:40 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: andy-chu (andy-chu) Assigned to: Nick Coghlan (ncoghlan) Summary: Add a -z interpreter flag to execute a zip file Initial Comment: The motivation for this is that distributing a zip file is a very light and easy way to distribute a python program with multiple packages/modules. I have done this on Linux, Mac and Windows and it works very nicely -- except that you need a few extra files to bootstrap it: set PYTHONPATH to the zip file and run the main function. With this small patch, you get rid of the need for extra files. At the bottom is a demo on Linux. On Windows, you can do a similar thing by making a file that is both a zip file and a batch file. The batch file will pass %~f0 (itself) to the -z flag of the Python interpreter. I ran this by Guido and he seemed to think it was a fine idea. At Google, we have numerous platform-specific hacks in a program called "autopar" to solve this problem. I have included the basic patch, but if you guys agree with this, I will add some tests and documentation. And I think it might be useful to include something in the Tools/ directory to do what update_zip.sh does below (add a __zipmain__ module and a shebang/batch file header to a zip file, to make it executable)? I think this may also help to fix a bug with eggs: http://peak.telecommunity.com/DevCenter/setuptools#eggsecutable-scripts IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or invoked via symlinks. They must be invoked using their original filename, in order to ensure that, once running, pkg_resources will know what project and version is in use. The header script will check this and exit with an error if the .egg file has been renamed or is invoked via a symlink that changes its base name. andychu testdata$ ls __zipmain__.py foo.py foo.pyc foo.zip foo_exe.zip header.txt update_zip.sh # The main program you're going to run in "development mode" andychu testdata$ ./foo.py foo bar argv: ['./foo.py', 'foo', 'bar'] # Same program, packaged into a zip file andychu testdata$ ./foo_exe.zip foo bar argv: ['-c', 'foo', 'bar'] # Contents of the zip file andychu testdata$ unzip -l foo_exe.zip Archive: foo_exe.zip warning [foo_exe.zip]: 51 extra bytes at beginning or within zipfile (attempting to process anyway) Length Date Time Name -------- ---- ---- ---- 243 06-18-07 20:01 __zipmain__.py 301 06-18-07 19:58 foo.py -------- ------- 544 2 files # Demo script to build an executable zip file. andychu testdata$ cat header.txt #!/usr/local/google/clients/python/trunk/python -z andychu testdata$ cat update_zip.sh #!/bin/bash # Make a regular zip file. zip foo.zip foo.py __zipmain__.py # Add a shebang line to it. cat header.txt foo.zip > foo_exe.zip # Make it executable. chmod 750 foo_exe.zip ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-06-30 00:40 Message: Logged In: YES user_id=1038590 Originator: NO I'm going to be off the net for a few days - I'll have a look at the updated patch when I get back late next week, ---------------------------------------------------------------------- Comment By: andy-chu (andy-chu) Date: 2007-06-28 15:17 Message: Logged In: YES user_id=1821575 Originator: YES Here is a script that documents how to make such files. I think the important part is just documenting the format. Then people can write whatever tools they need around it. Many people could get by with this simple tool, but others might want something more elaborate. Demo: andychu testprog$ find . ./__init__.py ./package1 ./package1/__init__.py ./package1/foo.py ./package1/lib.py ./package1/__init__.pyc ./package1/lib.pyc ./package1/foo.pyc andychu testprog$ find -name "*.py" | xargs ../Tools/scripts/makepyz.py -a zip,pyz,unix -z foo.zip -p package1 -m foo -y /usr/local/google/clients/python/trunk/python Added ./__init__.py to foo.zip Added ./package1/__init__.py to foo.zip Added ./package1/foo.py to foo.zip Added ./package1/lib.py to foo.zip Added __zipmain__.py to foo.zip Prepended #!/usr/local/google/clients/python/trunk/python -z to foo.zip. chmod foo.zip 0700 andychu testprog$ ./foo.zip lib module here argv: ['-c'] andychu testprog$ echo $? 3 File Added: makepyz.py ---------------------------------------------------------------------- Comment By: andy-chu (andy-chu) Date: 2007-06-27 15:35 Message: Logged In: YES user_id=1821575 Originator: YES Nick, I've updated the code to use a new runpy.run_zip function, which calls run_module. This does make it a bit cleaner. Let me know what you think. If the code is good I'll write some tests and documentation. Also, I'm not sure if the '-c' is really appropriate in sys.argv, but that seems to be what the -m flag uses. It seems like it might make sense to have sys.argv[0] be the zip file, if it is really a first class executable. And I think a script to build one of these files would be appropriate, which I can add. You could pass it the main module and main function, and it would generate a __zipmain__ stub and add it to the zip file. And it is a good idea if the file is cross platform, so a .pyz extension would work. Sorry the delayed response, I was a bit busy at work this week... but I'll respond sooner this time. : ) Example: andychu trunk$ testdata/foo_exe.zip foo bar __name__: __main__ argv: ['-c', 'foo', 'bar'] andychu trunk$ echo $? 3 File Added: runzip7.diff ---------------------------------------------------------------------- Comment By: andy-chu (andy-chu) Date: 2007-06-21 10:54 Message: Logged In: YES user_id=1821575 Originator: YES Nick, you're right, I think it can use run_module and be in the runpy module. Let me make those changes and send you another patch. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-06-19 21:21 Message: Logged In: YES user_id=1038590 Originator: NO I like the general idea, but it should be possible to use runpy.run_module to get __name__ set correctly (as that is what happens when you execute a module from a zipfile with -m). Another advantage of using run_module is that it would allow runzip() to take a second argument (possibly defaulting to "__zipmain__") which would specify the module to be executed from the zipfile (the remaining 3 run_module arguments could also be passed in, and set appropriately from main.c). Adding the new function as runpy.run_zip() (instead of adding a new module) would also be good. For Windows, an alternative to making the zip file both a batch and a zip file would be to adopt a .pyz extension convention for these files - the file associations can then be set up to invoke the script appropriately with python -z (similar to the way that .pyw files are associated with pythonw instead of the standard python executable). That way the same file could be executed on both Linux (via an embedded shebang line) and on Windows (via filename association), as is the case with standard .py Python scripts. My final question is whether the change to sys.path should be reverted once the module execution is complete - my suspicion is that it should, but I need to look into it a bit more before giving a definite answer (for the command line flag case, this behaviour obviously doesn't matter - it is only significant if the Python method is invoked directly in the context of a larger program). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1739468&group_id=5470 From noreply at sourceforge.net Sat Jun 30 19:38:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 Jun 2007 10:38:52 -0700 Subject: [Patches] [ python-Patches-1744382 ] Read Write lock Message-ID: Patches item #1744382, was opened at 2007-06-27 20:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yaakov Nemoy (loupgaroublond) Assigned to: Nobody/Anonymous (nobody) Summary: Read Write lock Initial Comment: This is a Lock for handling both multiple readers and a single or multiple writers. It allows any number of readers to acquire a 'lock' via a modified semaphore. It also allows any number of writers to try to acquire a lock, which signals the lock to block new readers from acquiring, until the writers have had a chance to do their business. Through a simple lock, multiple writers can wait in line, although only one writer can actually write at a time. It also lets the developer use the 'with' statement, via methods that return contextmanagers. I actually had a couple of unimplemented ideas. A) Writers can specify a deadline (or even use a default) such that after the deadline passes, the lock can use a callback to rollback/kill/pause readers, so that the writer doesn't wait an eternity. B) Allowing the semaphore to have an upper limit of allowed readers (or anythings), Since I don't need it, i never programmed it, but it should be fairly trivial to implement if there is any demand. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-06-30 19:38 Message: Logged In: YES user_id=21627 Originator: NO The patch is unacceptable in its current form: - it should be provided as a patch to threading.py, not as a separate module - it should have a name that follows "the convention", which seems to be that it should have "reader" and "writer" in its name (or "rw"). See how C# and Java do it (and other libraries you can find that provide such a mechanism) - it needs documentation - it needs tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1744382&group_id=5470