From noreply at sourceforge.net Thu Dec 1 17:39:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 08:39:10 -0800 Subject: [Patches] [ python-Patches-1314067 ] os.makedirs - robust against partial path Message-ID: Patches item #1314067, was opened at 2005-10-05 19:08 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs - robust against partial path Initial Comment: os.py function makedirs is intended to create a directory, including any required parent directories. Unfortunately, at least on windows, it fails is some of those parent directories already exist. This patch says "if the directory I'm about to create is already an existing directory, then pretend I succeeded and continue with the next step." ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-01 17:39 Message: Logged In: YES user_id=1207189 Hi, Could you provide some example code that shows up the error? If I understand you correctly, the following should fail: import os os.mkdir('c:/temp/a') os.makedirs('c:/temp/a/b/c') But it works fine on my WinXP pro SP2 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 From noreply at sourceforge.net Thu Dec 1 18:39:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 01 Dec 2005 09:39:53 -0800 Subject: [Patches] [ python-Patches-1371075 ] ConfigParser to accept a custom dict to allow ordering Message-ID: Patches item #1371075, was opened at 2005-12-01 17:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1371075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Micah Elliott (mdelliot) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser to accept a custom dict to allow ordering Initial Comment: In many cases it is preferrable for ConfigParser to maintain the order in which its items were added. This small change adds a `customdict` default argument to *ConfigParser's constructor to allow users to specify a custom dict. A useful example is:: from ConfigParser import ConfigParser ConfigParser(customdict=my_ordered_dict) One such `my_ordered_dict` could be the ordered dictionary "odict" . Ordered dictionaries have been a recent popular topic on comp.lang.python, and there are a few possibilities for implementation, so it seems best that ConfigParser just offer a default argument to support such customization. I can submit a documentation patch if this idea is accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1371075&group_id=5470 From noreply at sourceforge.net Fri Dec 2 14:44:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 05:44:50 -0800 Subject: [Patches] [ python-Patches-1367717 ] cgi: replace usage of UserDict with new dict class Message-ID: Patches item #1367717, was opened at 2005-11-27 21:30 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) >Summary: cgi: replace usage of UserDict with new dict class Initial Comment: replaces UserDict with new dict base class. Patch against python subversion repository revision 41544 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-30 05:28 Message: Logged In: YES user_id=80475 Wouldn't this change public cgi classes from old-style to new-style? Could it break user subclasses? Could it break code relying on the existence of self.data (which is unfortunately not a private variable name)? If so, I don't it is worth changing classes that are already documented as obsolete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 From noreply at sourceforge.net Fri Dec 2 17:07:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 08:07:57 -0800 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 21:42 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-02 17:07 Message: Logged In: YES user_id=1207189 Hi, Your patch "makedirs.py" for python 2.5 will fail under Windows if a drive letter is specified: >>> os.getcwd() 'C:\Temp\makedirs' >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'test.py'] >>> makedirs.makedirs('c:/temp/makedirs/a/b') >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'temp', 'test.py'] It will create the following path: C:\Temp\makedirs\temp\makedirs\a\b Also I ran it through the test suite (lib\test\test_os.py) and it failed one test: ====================================================================== FAIL: test_makedir (__main__.MakedirTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_os.py", line 327, in test_makedir self.failUnlessRaises(OSError, os.makedirs, os.curdir) AssertionError: OSError not raised ---------------------------------------------------------------------- I haven't looked into *why* this happens - I'll dig a bit deeper into this subject sometime next week. HTH, Richard ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:13 Message: Logged In: YES user_id=832344 Here is another patch, using simpler design, maybe for 2.5? The attached patch will try once to create each leaf in the path, ignoring existing leafs. This should work for most cases. If one run application that can delete its own directories, he should use proper locking. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 22:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 21:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Fri Dec 2 19:11:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 10:11:19 -0800 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-12-02 20:11 Message: Logged In: YES user_id=832344 The 2.5 code is only a proof of concept, don't use it as is :-) All the directories are handled in the same way - ignore OSError for existing directories, which is not compatible with the docs, that say it should raise an OSError for the last directory. This has to be fixed of course. I'll get 2.5 development code and submit a real working patch. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-02 18:07 Message: Logged In: YES user_id=1207189 Hi, Your patch "makedirs.py" for python 2.5 will fail under Windows if a drive letter is specified: >>> os.getcwd() 'C:\Temp\makedirs' >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'test.py'] >>> makedirs.makedirs('c:/temp/makedirs/a/b') >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'temp', 'test.py'] It will create the following path: C:\Temp\makedirs\temp\makedirs\a\b Also I ran it through the test suite (lib\test\test_os.py) and it failed one test: ====================================================================== FAIL: test_makedir (__main__.MakedirTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_os.py", line 327, in test_makedir self.failUnlessRaises(OSError, os.makedirs, os.curdir) AssertionError: OSError not raised ---------------------------------------------------------------------- I haven't looked into *why* this happens - I'll dig a bit deeper into this subject sometime next week. HTH, Richard ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:13 Message: Logged In: YES user_id=832344 Here is another patch, using simpler design, maybe for 2.5? The attached patch will try once to create each leaf in the path, ignoring existing leafs. This should work for most cases. If one run application that can delete its own directories, he should use proper locking. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Fri Dec 2 21:11:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 12:11:17 -0800 Subject: [Patches] [ python-Patches-1314067 ] os.makedirs - robust against partial path Message-ID: Patches item #1314067, was opened at 2005-10-05 13:08 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs - robust against partial path Initial Comment: os.py function makedirs is intended to create a directory, including any required parent directories. Unfortunately, at least on windows, it fails is some of those parent directories already exist. This patch says "if the directory I'm about to create is already an existing directory, then pretend I succeeded and continue with the next step." ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2005-12-02 15:11 Message: Logged In: YES user_id=764593 slight misdiagnosis on my part -- it only fails if the *entire* directory tree already exists. """ >>> os.makedirs('c:/temp/a/b/c') >>> os.makedirs('c:/temp/a/b/c') Traceback (most recent call last): File "", line 1, in -toplevel- os.makedirs('c:/temp/a/b/c') File "C:\Python24\lib\orig_os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 17] File exists: 'c:/temp/a/b/c' """ My use case was generating java files in the proper package - and possibly regenerating them if something changed. I want to put them in the right directory, which will usually (but not always) already exist. The patch still works, but I now wonder if it might be better to put a guard at the top along the lines of "if path.exists(name): return" (or something fancier to ensure that it is a directory with appropriate permissions). ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-01 11:39 Message: Logged In: YES user_id=1207189 Hi, Could you provide some example code that shows up the error? If I understand you correctly, the following should fail: import os os.mkdir('c:/temp/a') os.makedirs('c:/temp/a/b/c') But it works fine on my WinXP pro SP2 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 From noreply at sourceforge.net Sat Dec 3 03:04:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Dec 2005 18:04:48 -0800 Subject: [Patches] [ python-Patches-1372125 ] fix UnixBrowswer failure when no browser running Message-ID: Patches item #1372125, was opened at 2005-12-02 18: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=1372125&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: fix UnixBrowswer failure when no browser running Initial Comment: See discussions in bug #1352621 and bug #1338995 for even more details. Background: The webbrowser.py was modified, post-Python 2.4.2, to tell whether or not the browser invocation succeeded or not. Unfortunately, the modifications caused Python applications to hang when no browser was already present. And the reputed fix for bug #1338995, revision 41419, only made things worse for UnixBrowsers. Fix: The changes to webbrowser.py were well intentioned, but failed because it was difficult to tell if invocation succeeded due to an extra level of indirection in invoking the browser by using os.system(). The attached patch, for revision 41511, uses subprocess.Popen() instead for UnixBrowser. The other uses of os.system() would also benefit, but are less critical to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372125&group_id=5470 From noreply at sourceforge.net Sun Dec 4 14:54:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 05:54:08 -0800 Subject: [Patches] [ python-Patches-1372836 ] tiny chunk of unused code in cookielib Message-ID: Patches item #1372836, was opened at 2005-12-04 13: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=1372836&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: tiny chunk of unused code in cookielib Initial Comment: Nothing to add to the summary... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372836&group_id=5470 From noreply at sourceforge.net Sun Dec 4 15:30:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 06:30:06 -0800 Subject: [Patches] [ python-Patches-686545 ] Add addition and moving messages to mailbox module Message-ID: Patches item #686545, was opened at 2003-02-14 08:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) >Summary: Add addition and moving messages to mailbox module Initial Comment: The Maildir class in the mailbox module only supports reading a Maildir. The attached patch adds methods for adding messages and moving them from folder to folder within the Maildir. The mailbox test suite is also expanded to actually exercise the Maildir code a bit. This patch doesn't include the required documentation. For now I just want a review of the interface (are add_message() and move_message() all we need? are the parameters right?). and of the code. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 09:30 Message: Logged In: YES user_id=11375 This patch is now superseded by Gregory Johnson's Summer of Code work, which adds write support to all the mailbox classes, not just Maildir, and also includes the documentation changes. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-14 08:43 Message: Logged In: YES user_id=11375 Thank you, sir; may I have another? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 From noreply at sourceforge.net Sun Dec 4 15:30:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 06:30:24 -0800 Subject: [Patches] [ python-Patches-686545 ] Add addition and moving messages to mailbox module Message-ID: Patches item #686545, was opened at 2003-02-14 08:42 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 Please note that this 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: 8 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Add addition and moving messages to mailbox module Initial Comment: The Maildir class in the mailbox module only supports reading a Maildir. The attached patch adds methods for adding messages and moving them from folder to folder within the Maildir. The mailbox test suite is also expanded to actually exercise the Maildir code a bit. This patch doesn't include the required documentation. For now I just want a review of the interface (are add_message() and move_message() all we need? are the parameters right?). and of the code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 09:30 Message: Logged In: YES user_id=11375 This patch is now superseded by Gregory Johnson's Summer of Code work, which adds write support to all the mailbox classes, not just Maildir, and also includes the documentation changes. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-02-14 08:43 Message: Logged In: YES user_id=11375 Thank you, sir; may I have another? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=686545&group_id=5470 From noreply at sourceforge.net Sun Dec 4 15:46:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 06:46:12 -0800 Subject: [Patches] [ python-Patches-1367717 ] cgi: replace usage of UserDict with new dict class Message-ID: Patches item #1367717, was opened at 2005-11-27 21:30 Message generated for change (Comment added) made by tds33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 Please note that this 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: None >Priority: 1 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: cgi: replace usage of UserDict with new dict class Initial Comment: replaces UserDict with new dict base class. Patch against python subversion repository revision 41544 ---------------------------------------------------------------------- >Comment By: Wolfgang Langner (tds33) Date: 2005-12-04 15:46 Message: Logged In: YES user_id=600792 Yes it could break old code. And yes it is not worth changing this class. I missed the comment. This was aplphabeticaly the first module with usage of UserDict and so my first choice for change. :-) So I close this patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-30 05:28 Message: Logged In: YES user_id=80475 Wouldn't this change public cgi classes from old-style to new-style? Could it break user subclasses? Could it break code relying on the existence of self.data (which is unfortunately not a private variable name)? If so, I don't it is worth changing classes that are already documented as obsolete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367717&group_id=5470 From noreply at sourceforge.net Sun Dec 4 17:10:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 08:10:35 -0800 Subject: [Patches] [ python-Patches-1372836 ] tiny chunk of unused code in cookielib Message-ID: Patches item #1372836, was opened at 2005-12-04 08:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372836&group_id=5470 Please note that this 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 Submitted By: John J Lee (jjlee) >Assigned to: A.M. Kuchling (akuchling) Summary: tiny chunk of unused code in cookielib Initial Comment: Nothing to add to the summary... ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 11:10 Message: Logged In: YES user_id=11375 Patch committed in rev41588. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372836&group_id=5470 From noreply at sourceforge.net Sun Dec 4 17:35:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 08:35:13 -0800 Subject: [Patches] [ python-Patches-893642 ] SimpleXMLRPCServer.py optional allow_none argument Message-ID: Patches item #893642, was opened at 2004-02-09 14:59 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 Please note that this 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 Submitted By: Li Zou (lzou) >Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer.py optional allow_none argument Initial Comment: xmlrpclip.ServerProxy support an optional allow_none argument while SimpleXMLRPCServer.py doesn't. This patch is a straightforward one to fix it. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 11:35 Message: Logged In: YES user_id=11375 Applied in rev.41589; thanks! ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 04:13 Message: Logged In: YES user_id=23486 Updated patch to fix CGIXMLRPCRequestHandler & added patch to Lib/ documentation. New diffs against current head available at http://issola.caltech.edu/~t/transfer/patch-893642-xmlrpc.diff This patch should not change any behavior. It only allows overriding of default behavior (which is to not allow_none). Recommend apply. ---------------------------------------------------------------------- Comment By: Mark McClain (mmcclain) Date: 2004-02-17 16:57 Message: Logged In: YES user_id=978042 The patch needs to address the CGIXMLDispatcher too. Otherwise it is the same as the one that I did last fall, but have been slow to post here. ---------------------------------------------------------------------- Comment By: Mark McClain (mmcclain) Date: 2004-02-17 16:54 Message: Logged In: YES user_id=978042 The patch needs to address the CGIXMLDispatcher too. Otherwise it is the same as the one that I did last fall, but have been slow to post here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 From noreply at sourceforge.net Sun Dec 4 17:36:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 08:36:23 -0800 Subject: [Patches] [ python-Patches-1212287 ] mode argument for fileinput class Message-ID: Patches item #1212287, was opened at 2005-05-31 22:41 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: mode argument for fileinput class Initial Comment: This patch is in follow-up to bug #860515. It allows to specify a mode argument to the fileinput functions which can be r, rb, rU and U. Complete with test and doc. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 16:36 Message: Logged In: YES user_id=261020 I reviewed this patch and ran the test. Looks good to me. The docs need a \versionchanged for each of the two changed callables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212287&group_id=5470 From noreply at sourceforge.net Sun Dec 4 17:59:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 08:59:22 -0800 Subject: [Patches] [ python-Patches-1039083 ] SimpleXMLRPCServer optional allow_none / encoding arguments Message-ID: Patches item #1039083, was opened at 2004-10-02 13:40 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guillermo M. Narvaja (guillon) >Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer optional allow_none / encoding arguments Initial Comment: xmlrpclip.ServerProxy supports an optional allow_none and encoding arguments while SimpleXMLRPCServer.py doesn't. The patch adds optional arguments to SimpleXMLRPCDispatcher, SimpleXMLRPCServer and CGIXMLRPCRequestHandler. "encoding" and "allow_none" arguments are passed to xmlrpclib.dumps calls in _marshalled_dispatch method. ---------------------------------------------------------------------- Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 13:52 Message: Logged In: YES user_id=1132014 Old file removed. ---------------------------------------------------------------------- Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 13:50 Message: Logged In: YES user_id=1132014 Fixed some large lines to fit in 78 columns. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 From noreply at sourceforge.net Sun Dec 4 18:01:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 09:01:16 -0800 Subject: [Patches] [ python-Patches-1215184 ] two fileinput enhancements (fileno, openhook) Message-ID: Patches item #1215184, was opened at 2005-06-05 15:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1215184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: two fileinput enhancements (fileno, openhook) Initial Comment: These two patches enhance the fileinput module. The fileno patch adds a "fileno()" method that returns the current file number. The openhook patch adds a possibility to specify an opening hook, that is, instead of calling open(), the hook is called. This is useful, for example, for transparently decompressing gzip files, as wished in RFE #563141. Docs and tests will be added if this is welcomed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 17:01 Message: Logged In: YES user_id=261020 I don't see any attached openhook patch. The fileno patch looks fine, but personally I would indeed welcome docs and tests :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1215184&group_id=5470 From noreply at sourceforge.net Sun Dec 4 18:13:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 09:13:38 -0800 Subject: [Patches] [ python-Patches-1039083 ] SimpleXMLRPCServer optional allow_none / encoding arguments Message-ID: Patches item #1039083, was opened at 2004-10-02 13:40 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Guillermo M. Narvaja (guillon) Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer optional allow_none / encoding arguments Initial Comment: xmlrpclip.ServerProxy supports an optional allow_none and encoding arguments while SimpleXMLRPCServer.py doesn't. The patch adds optional arguments to SimpleXMLRPCDispatcher, SimpleXMLRPCServer and CGIXMLRPCRequestHandler. "encoding" and "allow_none" arguments are passed to xmlrpclib.dumps calls in _marshalled_dispatch method. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 12:13 Message: Logged In: YES user_id=11375 Applied to rev41591; thanks for your patch! ---------------------------------------------------------------------- Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 13:52 Message: Logged In: YES user_id=1132014 Old file removed. ---------------------------------------------------------------------- Comment By: Guillermo M. Narvaja (guillon) Date: 2004-10-02 13:50 Message: Logged In: YES user_id=1132014 Fixed some large lines to fit in 78 columns. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1039083&group_id=5470 From noreply at sourceforge.net Sun Dec 4 20:37:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 11:37:32 -0800 Subject: [Patches] [ python-Patches-1372995 ] Missing \versionadded in urllib2 and cookielib docs Message-ID: Patches item #1372995, was opened at 2005-12-04 19: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=1372995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Missing \versionadded in urllib2 and cookielib docs Initial Comment: Nothing to add to the summary, except: - Can't build the docs on this machine, hence untested - Could be backported to 2.4 branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372995&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:01:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:01:05 -0800 Subject: [Patches] [ python-Patches-1216942 ] Suggested Additional Material for urllib2 docs Message-ID: Patches item #1216942, was opened at 2005-06-08 10:41 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Suggested Additional Material for urllib2 docs Initial Comment: This is some suggested additional material for the urllib2 docs. Particularly the part about error codes and the reason/code attributes of error objects is *missing* from the manual and needed. Also the example showing basic Authentication using password manager/handler/opener may help avoid some confusion. Alternatively you can link to my online tutorials at http://www.voidspace.org.uk/python/articles.shtml#http :-) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:01 Message: Logged In: YES user_id=261020 I'm sure doc improvements are welcome here, so thank you :) However, I think you need to 1) split this up into small patches that address very specific issues, and briefly justify each change in the patch submission note on the SF patch tracker 2) present the patches by editing the original .tex source files from src/Doc/lib and then running 'diff -u' or 'svn diff' (it doesn't matter if you can't compile the docs or get the TeX markup wrong, just as long as everybody can see exactly what the intended changes to the text are) Also, one thing that caught my eye on a very brief scan was that the actual response code->name mapping (rather than a note to document the existence of that mapping) shouldn't be reproduced in the docs, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:20:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:20:18 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-12-04 20:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 15:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 18:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:25:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:25:54 -0800 Subject: [Patches] [ python-Patches-1372995 ] Missing \versionadded in urllib2 and cookielib docs Message-ID: Patches item #1372995, was opened at 2005-12-04 14:37 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: A.M. Kuchling (akuchling) Summary: Missing \versionadded in urllib2 and cookielib docs Initial Comment: Nothing to add to the summary, except: - Can't build the docs on this machine, hence untested - Could be backported to 2.4 branch. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-04 15:25 Message: Logged In: YES user_id=11375 Applied; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372995&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:37:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:37:05 -0800 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-04 19:20 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah <pre> # Test to see if forkpty works. (But don't worry if it isn't available.) import os, time from test.test_support import verbose, TestFailed, TestSkipped try: if verbose: print 'Calling os.forkpty()' pid, fd = os.forkpty() except AttributeError: raise TestSkipped, 'No os.forkpty() available.' if pid == 0: # child print 'I am not a robot!' else: if verbose: print '(pid, fd) = (%d, %d)' % (pid, fd) time.sleep(1) # Give the child a chance to print. print 'Robots always say:', os.read(fd,100) os.close(fd) </pre> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-28 13:17 Message: Logged In: YES user_id=21627 In the absence of a patch that is known to work on all relevant platforms, there is nothing really to revisit. Most likely, the next action on this patch is to reject it, unless somebody steps forward to do the remaining work. ---------------------------------------------------------------------- Comment By: Richard A. Holden III (aciddeath) Date: 2005-03-22 14:49 Message: Logged In: YES user_id=591527 Would it be possible to revisit this since we are now on 2.4? I am developing on pexpect and having this would greatly simplify my life. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-13 13:46 Message: Logged In: YES user_id=29957 Google for "HP testdrive". DEC^W Digital^W Compaq^W HP have a farm of test systems you can use for testing. ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2003-09-03 16:07 Message: Logged In: YES user_id=59261 Is there a place where a prospective developer can test on these 8 platforms? I read the Developer FAQ and have been going through the School of Hard Knocks: http://mail.python.org/pipermail/python-dev/2002- September/028725.html I would like to work with someone on this as I only have access to the platforms on Compile Farm from SourceForge. The fact that ptmx support causes HP-UX to hang is probably a simple configuration problem (perhaps incorrectly defining HAVE_DEV_PTMX), but it's impossible for me to research this using only the Compile Farm. Yours, Noah ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 16:27 Message: Logged In: YES user_id=21627 The addition of support for ptmx inside posix.openpty has caused the test suite to hang on HP-UX and other systems. A good strategy would be to find some code base, and rigorously test these on all 8 or so supported Unix variants. I'm willing to accept any code that has been tested so, but only after Python 2.3. ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2003-07-13 15:52 Message: Logged In: YES user_id=59261 Which openpty has made pty handling unusable? There are two: os.openpty() and pty.openpty(). What is a good strategy for making pty handling more consistent? I think it's impossible to make pty handling totally platform independent, but Python's pty module could certainly be cleaned up to hide the ugliness. Platforms that are not explicitly handled should probably not define forkpty. Currently Solaris uses the wrong code -- thus leaving the user with the impression that Solaris is supported, but providing a broken implementation. Pty handling is a headache -- I never understood why it was overlooked by POSIX given that ptys are critical to every UNIX system. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 11:08 Message: Logged In: YES user_id=21627 It should be deferred. Mere addition of openpty has nearly made the entire pty handling nearly unusable on some systems, as the C library versions of these functions tend to be buggy beyond repair. So I'd rather don't add any more breakage here. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-13 10:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply at sourceforge.net Sun Dec 4 21:41:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 12:41:27 -0800 Subject: [Patches] [ python-Patches-813436 ] Scalable zipfile extension Message-ID: Patches item #813436, was opened at 2003-09-27 04:09 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813436&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Marc De Falco (deufeufeu) Assigned to: Nobody/Anonymous (nobody) Summary: Scalable zipfile extension Initial Comment: Playing around with large zipfiles (> 10000 files), I've encountered big loading time, even if after having loaded it I use only 30 files in it. So I've introduced a differed parameter to the Zipfile.__init__ in order to load headers on-demand. As it's not a really good idea to activated it for all zip it defaults to False. I've updated the documentation too. Thx and keep the good work ;) P.S. : Dunno if it can be added to 2.3 or have to be included in 2.4, so I've choosed 2.4 group. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=813436&group_id=5470 From noreply at sourceforge.net Mon Dec 5 00:09:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 15:09:38 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-12-04 23:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 15:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 18:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Mon Dec 5 02:08:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 17:08:00 -0800 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:08 Message: Logged In: YES user_id=832344 I deleted both patches as they are both wrong: The patch against 2.4.1 will not raise OSError when trying to create existing directories. The simpler code for 2.5 will not work because os.path.normpath is not safe to use if the path contain symbolic links. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-02 20:11 Message: Logged In: YES user_id=832344 The 2.5 code is only a proof of concept, don't use it as is :-) All the directories are handled in the same way - ignore OSError for existing directories, which is not compatible with the docs, that say it should raise an OSError for the last directory. This has to be fixed of course. I'll get 2.5 development code and submit a real working patch. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-02 18:07 Message: Logged In: YES user_id=1207189 Hi, Your patch "makedirs.py" for python 2.5 will fail under Windows if a drive letter is specified: >>> os.getcwd() 'C:\Temp\makedirs' >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'test.py'] >>> makedirs.makedirs('c:/temp/makedirs/a/b') >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'temp', 'test.py'] It will create the following path: C:\Temp\makedirs\temp\makedirs\a\b Also I ran it through the test suite (lib\test\test_os.py) and it failed one test: ====================================================================== FAIL: test_makedir (__main__.MakedirTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_os.py", line 327, in test_makedir self.failUnlessRaises(OSError, os.makedirs, os.curdir) AssertionError: OSError not raised ---------------------------------------------------------------------- I haven't looked into *why* this happens - I'll dig a bit deeper into this subject sometime next week. HTH, Richard ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:13 Message: Logged In: YES user_id=832344 Here is another patch, using simpler design, maybe for 2.5? The attached patch will try once to create each leaf in the path, ignoring existing leafs. This should work for most cases. If one run application that can delete its own directories, he should use proper locking. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Mon Dec 5 02:21:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Dec 2005 17:21:33 -0800 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:21 Message: Logged In: YES user_id=832344 Please review this new patch, tested with current 2.5 code. I factored duplicate code in makedirs and removedirs into private _splits function, kind of the "super" version of os.path.split for the "super" directory utilities. I also simplified the test code for makedirs, and added more test cases. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:08 Message: Logged In: YES user_id=832344 I deleted both patches as they are both wrong: The patch against 2.4.1 will not raise OSError when trying to create existing directories. The simpler code for 2.5 will not work because os.path.normpath is not safe to use if the path contain symbolic links. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-02 20:11 Message: Logged In: YES user_id=832344 The 2.5 code is only a proof of concept, don't use it as is :-) All the directories are handled in the same way - ignore OSError for existing directories, which is not compatible with the docs, that say it should raise an OSError for the last directory. This has to be fixed of course. I'll get 2.5 development code and submit a real working patch. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-02 18:07 Message: Logged In: YES user_id=1207189 Hi, Your patch "makedirs.py" for python 2.5 will fail under Windows if a drive letter is specified: >>> os.getcwd() 'C:\Temp\makedirs' >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'test.py'] >>> makedirs.makedirs('c:/temp/makedirs/a/b') >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'temp', 'test.py'] It will create the following path: C:\Temp\makedirs\temp\makedirs\a\b Also I ran it through the test suite (lib\test\test_os.py) and it failed one test: ====================================================================== FAIL: test_makedir (__main__.MakedirTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_os.py", line 327, in test_makedir self.failUnlessRaises(OSError, os.makedirs, os.curdir) AssertionError: OSError not raised ---------------------------------------------------------------------- I haven't looked into *why* this happens - I'll dig a bit deeper into this subject sometime next week. HTH, Richard ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:13 Message: Logged In: YES user_id=832344 Here is another patch, using simpler design, maybe for 2.5? The attached patch will try once to create each leaf in the path, ignoring existing leafs. This should work for most cases. If one run application that can delete its own directories, he should use proper locking. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From noreply at sourceforge.net Mon Dec 5 13:39:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 04:39:18 -0800 Subject: [Patches] [ python-Patches-1314067 ] os.makedirs - robust against partial path Message-ID: Patches item #1314067, was opened at 2005-10-05 19:08 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs - robust against partial path Initial Comment: os.py function makedirs is intended to create a directory, including any required parent directories. Unfortunately, at least on windows, it fails is some of those parent directories already exist. This patch says "if the directory I'm about to create is already an existing directory, then pretend I succeeded and continue with the next step." ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-05 13:39 Message: Logged In: YES user_id=1207189 I think that the current behavior of the function is correct. It tries to mimic os.mkdir - if the dir to create ("c" in your example) already exists, it will raise an error. However, errors on intermediate dirs are ignored. This makes sense, but I think the documentation is not clear on this (or maybe I'm just slow :-) BTW - there's another patch ([ 1239890 ] Prevent race condition in os.makedirs) to rewrite the whole function and it might make your patch in its current form obsolete. Maybe your work can be merged into this other patch? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-12-02 21:11 Message: Logged In: YES user_id=764593 slight misdiagnosis on my part -- it only fails if the *entire* directory tree already exists. """ >>> os.makedirs('c:/temp/a/b/c') >>> os.makedirs('c:/temp/a/b/c') Traceback (most recent call last): File "", line 1, in -toplevel- os.makedirs('c:/temp/a/b/c') File "C:\Python24\lib\orig_os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 17] File exists: 'c:/temp/a/b/c' """ My use case was generating java files in the proper package - and possibly regenerating them if something changed. I want to put them in the right directory, which will usually (but not always) already exist. The patch still works, but I now wonder if it might be better to put a guard at the top along the lines of "if path.exists(name): return" (or something fancier to ensure that it is a directory with appropriate permissions). ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-01 17:39 Message: Logged In: YES user_id=1207189 Hi, Could you provide some example code that shows up the error? If I understand you correctly, the following should fail: import os os.mkdir('c:/temp/a') os.makedirs('c:/temp/a/b/c') But it works fine on my WinXP pro SP2 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1314067&group_id=5470 From noreply at sourceforge.net Mon Dec 5 13:46:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 04:46:29 -0800 Subject: [Patches] [ python-Patches-1239890 ] Prevent race condition in os.makedirs Message-ID: Patches item #1239890, was opened at 2005-07-17 22:42 Message generated for change (Comment added) made by nirs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nir Soffer (nirs) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent race condition in os.makedirs Initial Comment: makedirs check if a directory exists, and call mkdir to create it. In rare cases, the directory might have been created by another process or thread in the time passed from the exists() call to the mkdir() call. To prevent this rare race condition, use try: expect: to create the directory, then ignore "File exists" errors, which mean the directory was there. ---------------------------------------------------------------------- >Comment By: Nir Soffer (nirs) Date: 2005-12-05 14:46 Message: Logged In: YES user_id=832344 Sorry, here is the patch. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:21 Message: Logged In: YES user_id=832344 Please review this new patch, tested with current 2.5 code. I factored duplicate code in makedirs and removedirs into private _splits function, kind of the "super" version of os.path.split for the "super" directory utilities. I also simplified the test code for makedirs, and added more test cases. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-05 03:08 Message: Logged In: YES user_id=832344 I deleted both patches as they are both wrong: The patch against 2.4.1 will not raise OSError when trying to create existing directories. The simpler code for 2.5 will not work because os.path.normpath is not safe to use if the path contain symbolic links. ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-12-02 20:11 Message: Logged In: YES user_id=832344 The 2.5 code is only a proof of concept, don't use it as is :-) All the directories are handled in the same way - ignore OSError for existing directories, which is not compatible with the docs, that say it should raise an OSError for the last directory. This has to be fixed of course. I'll get 2.5 development code and submit a real working patch. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-02 18:07 Message: Logged In: YES user_id=1207189 Hi, Your patch "makedirs.py" for python 2.5 will fail under Windows if a drive letter is specified: >>> os.getcwd() 'C:\Temp\makedirs' >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'test.py'] >>> makedirs.makedirs('c:/temp/makedirs/a/b') >>> os.listdir('.') ['makedirs.py', 'makedirs.pyc', 'temp', 'test.py'] It will create the following path: C:\Temp\makedirs\temp\makedirs\a\b Also I ran it through the test suite (lib\test\test_os.py) and it failed one test: ====================================================================== FAIL: test_makedir (__main__.MakedirTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_os.py", line 327, in test_makedir self.failUnlessRaises(OSError, os.makedirs, os.curdir) AssertionError: OSError not raised ---------------------------------------------------------------------- I haven't looked into *why* this happens - I'll dig a bit deeper into this subject sometime next week. HTH, Richard ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-18 00:13 Message: Logged In: YES user_id=832344 Here is another patch, using simpler design, maybe for 2.5? The attached patch will try once to create each leaf in the path, ignoring existing leafs. This should work for most cases. If one run application that can delete its own directories, he should use proper locking. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 23:13 Message: Logged In: YES user_id=1188172 http://sourceforge.net/tracker/index.php?func=detail&aid=1223238&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Nir Soffer (nirs) Date: 2005-07-17 23:06 Message: Logged In: YES user_id=832344 I can't find such bug or patch. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-17 22:57 Message: Logged In: YES user_id=1188172 See bug #1223238. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1239890&group_id=5470 From G.S.-Design at t-online.de Mon Dec 5 13:43:04 2005 From: G.S.-Design at t-online.de (G.S.-Design@t-online.de) Date: Mon, 5 Dec 2005 13:43:04 +0100 Subject: [Patches] Healthy and rich with triple money back warranty Message-ID: <1EjFgr-1jdYEq0@fwd29.sul.t-online.de> Guarantee your success with 3 to be free Wolfgang here with a quick note... Healthy and realm, is that not each dream. This could be a way. http://715110729.3tobefree.com If not your right way, you have at least a small profit. (Five days for money ore triple money back) (No Spam, TKG ? 107/letter 4) If you never want Information from me, please remove this mail to me, and I delete your address. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20051205/33d5f8d2/attachment.htm From noreply at sourceforge.net Mon Dec 5 17:42:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 08:42:45 -0800 Subject: [Patches] [ python-Patches-1373643 ] chunk.py can't handle >2GB chunks Message-ID: Patches item #1373643, was opened at 2005-12-05 17:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373643&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christer Weinigel (wingel) Assigned to: Nobody/Anonymous (nobody) Summary: chunk.py can't handle >2GB chunks Initial Comment: chunk.py unpacks the chunk size as a signed long 'l' not as unsigned long 'L' which is what it ought to do according to the WAV specs. Additionally, since field contains a byte count it makes no sense for it to be signed. What I want to do is to read a wave file generated by madplay on the fly. Since madplay doesn't know the size of the WAVE chunk when it is written, it sets the chunk size to 0xffff which is inpreted as -1 by chunk.py . Changing chunk.py to read it as an unsigned long makes this work. Example code: import wave import os f = os.popen('madplay -o wave:- foo.mp3') wf = wave.open(f, 'rb') Without a patch, this will raise an error: wave.Error: not a WAVE file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373643&group_id=5470 From noreply at sourceforge.net Mon Dec 5 20:21:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 11:21:18 -0800 Subject: [Patches] [ python-Patches-1373762 ] Tweak pprint.PrettyPrinter.format for subclassing Message-ID: Patches item #1373762, was opened at 2005-12-05 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Tweak pprint.PrettyPrinter.format for subclassing Initial Comment: The current format() method doesn't recursively apply an overridden format() method when the width of the object is too short. This patch is designed to remove that limitation and allow a pprint.PrettyPrinter sublcass that could, for example, print all ints and longs in hex: class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] The attached file contains "svn diff --diff-cmd diff - x -b Lib/pprint.py". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 From noreply at sourceforge.net Mon Dec 5 20:42:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 11:42:18 -0800 Subject: [Patches] [ python-Patches-1373762 ] Tweak pprint.PrettyPrinter.format for subclassing Message-ID: Patches item #1373762, was opened at 2005-12-05 14:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tweak pprint.PrettyPrinter.format for subclassing Initial Comment: The current format() method doesn't recursively apply an overridden format() method when the width of the object is too short. This patch is designed to remove that limitation and allow a pprint.PrettyPrinter sublcass that could, for example, print all ints and longs in hex: class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] The attached file contains "svn diff --diff-cmd diff - x -b Lib/pprint.py". ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-05 14:42 Message: Logged In: YES user_id=80475 I don't find the use case to be even slightly motivating. Fred, what do you think of the patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 From noreply at sourceforge.net Mon Dec 5 21:48:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 12:48:45 -0800 Subject: [Patches] [ python-Patches-1373762 ] Tweak pprint.PrettyPrinter.format for subclassing Message-ID: Patches item #1373762, was opened at 2005-12-05 14:21 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tweak pprint.PrettyPrinter.format for subclassing Initial Comment: The current format() method doesn't recursively apply an overridden format() method when the width of the object is too short. This patch is designed to remove that limitation and allow a pprint.PrettyPrinter sublcass that could, for example, print all ints and longs in hex: class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] The attached file contains "svn diff --diff-cmd diff - x -b Lib/pprint.py". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-12-05 15:48 Message: Logged In: YES user_id=3066 Heh, reading the diff alone doesn't help me; there's no helpful context. While the example use case doesn't seem interesting, I consider non-support of sub-class overriding the format() method to be a bug. I'll try and look at the patch more seriously soon, but I've not managed to eek out many tuits lately, and this week is as massively overbooked as any these days. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-05 14:42 Message: Logged In: YES user_id=80475 I don't find the use case to be even slightly motivating. Fred, what do you think of the patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 From noreply at sourceforge.net Mon Dec 5 23:17:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 14:17:35 -0800 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 18:09 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-12-05 22:17 Message: Logged In: YES user_id=6656 Here's a patch updated to SVN HEAD (the PEP 342 implementation meant this wasn't quite trivial). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 19:37 Message: Logged In: YES user_id=6656 > Is it worth adding a comment on parsing precedence? I've been studiously avoiding thinking about that :) > Making something both an instance and a subclass of > anything besides object might be weird enough that you > don't *want* to document the results yet. Quite. What happens, happens IMHO. I'm prepared to be argued into a different position on this, but I do think the only reason someone would do this is curiousity :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 17:51 Message: Logged In: YES user_id=764593 Is it worth adding a comment on parsing precedence? An object can be both an instance and a class, which puts some ambiguity between "raise class" and "raise classinstance". Assuming the class seems sensible; I'm just wondering whether it should be made explicit. (Making something both an instance and a subclass of anything besides object might be weird enough that you don't *want* to document the results yet.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 17:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 17:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 16:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 16:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 15:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 14:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 13:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 19:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Mon Dec 5 23:28:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 14:28:53 -0800 Subject: [Patches] [ python-Patches-1157027 ] cookielib mis-handles RFC 2109 cookies in Netscape mode Message-ID: Patches item #1157027, was opened at 2005-03-04 23:09 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1157027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib mis-handles RFC 2109 cookies in Netscape mode Initial Comment: cookielib treats RFC 2109 cookies as RFC 2965 even when functioning as a pure Netscape protocol implementation (ie. when RFC 2965 handling is disabled by setting a CookiePolicy instance's rfc2965 attribute false). This is not correct: the Netscape cookie protocol, in the absence of RFC 2965 (yes, BTW: RFC 2965 and its unfinished errata say that RFC 2965 and Netscape handling are supposed to interact with each other, in complicated and ill-defined ways), treats RFC 2109 cookies as Netscape cookies. Background: The Netscape protocol is an ad-hoc standard defined by the MSIE and Mozilla browser implementations. A Netscape cookie is one set in the Set-Cookie header with no version cookie-attribute. An RFC 2109 cookie is a one set in the Set-Cookie header with a version cookie-attribute of 1. An RFC 2965 cookie is a one set in the Set-Cookie2 (note the '2') header with a version cookie-attribute of 1. Popular browsers treat RFC 2109 cookies as Netscape cookies (which, ad-hoc as Netscape cookies are, effectively include a few bits and pieces from the 2109 standard). The bug breaks apps like Mailman that (naively or stubbornly) send RFC 2109 cookies. The patch treats RFC 2109 cookies as Netscape cookies if RFC 2965 handling is turned off. (It also removes two no-op lines of code at around line 1304). Test and doc patches are included. 2.4 backport candidate. (The bug was uncovered by the switch, in the patch originally accepted to Python stdlib, to RFC 2965 handling being off by default. Earlier versions of ClientCookie had RFC 2965 off by default.) ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-12-05 22:28 Message: Logged In: YES user_id=261020 Since this didn't get applied in 2.4.1 or 2.4.2, I have uploaded a new patch for 2.5, and deleted the original patch attached to this tracker item. Tests and documentation changes are included in the patch. In addition to fixing the bug described in the original patch comment, this patch (rfc2109-2.patch) adds two new attributes (hence should not be back-ported): 1. Cookie instances have an rfc2109 attribute. This attribute is true if the cookie was received as an RFC 2109 cookie (ie. the cookie arrived in a \mailheader{Set-Cookie} header, and the value of the Version cookie-attribute in that header was 1). 2. DefaultCookiePolicy instances have an rfc2109_as_netscape attribute. Assigning to this attribute allows explicit control over whether RFC 2109 cookies are 'downgraded' to Netscape cookies. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:11 Message: Logged In: YES user_id=261020 > (...Earlier versions of ClientCookie had RFC 2965 off by default.) I meant to say: > (...Earlier versions of ClientCookie had RFC 2965 on by default.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1157027&group_id=5470 From noreply at sourceforge.net Mon Dec 5 23:54:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 14:54:21 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-12-05 22:54 Message: Logged In: YES user_id=261020 OK, another patch applied since March causes loaderror_v2.patch to add a class statement which is already present in the patched file. loaderror_v3.patch fixes that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 23:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 15:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 18:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Tue Dec 6 05:14:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 20:14:58 -0800 Subject: [Patches] [ python-Patches-1374063 ] Broader iterable support for xmlrpclib Message-ID: Patches item #1374063, was opened at 2005-12-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=1374063&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Broader iterable support for xmlrpclib Initial Comment: The XML-RPC spec supports a fairly limited set of datatypes. Most languages, Python included, contain many more types than XML-RPC. Some types, such as Python's complex number type, have no reasonable analog in XML-RPC. Others, such as unicode objects and array objects do. This patch allows anything that can be converted to a list but that is not otherwise supported directly by the xmlrpclib module already to be marshalled as an XML-RPC array if the allow_iter parameter to the ServerProxy constructor evaluated to true. This includes sets and arrays. Motivation... 1. Python already overloads the XML-RPC array type with both lists and tuples. This just extends that overloading to other currently unsupported Python types which can be converted to lists. Why should lists and tuples have all the fun? 2. Providing transparent conversion to XML-RPC arrays keeps calling code a bit cleaner. One of the attractions of XML-RPC is that the remote procedure call looks identical to a local call. This is especially true in Python because of /F's excellent little _Method class. Clearly as a programmer I could type: import array a = array.array('i', [1, 2,3]) ... from somemodule import somefunction print somefunction(list(a)) but that reveals details of the implementation of somefunction, namely that it can't handle arrays directly, even though in most respects arrays and lists are interchangeable. Attached is a patch for the xmlrpclib library that implements this feature, including minor doc changes and a new test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1374063&group_id=5470 From noreply at sourceforge.net Tue Dec 6 05:23:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Dec 2005 20:23:50 -0800 Subject: [Patches] [ python-Patches-1374063 ] Broader iterable support for xmlrpclib Message-ID: Patches item #1374063, was opened at 2005-12-05 22:14 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1374063&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Broader iterable support for xmlrpclib Initial Comment: The XML-RPC spec supports a fairly limited set of datatypes. Most languages, Python included, contain many more types than XML-RPC. Some types, such as Python's complex number type, have no reasonable analog in XML-RPC. Others, such as unicode objects and array objects do. This patch allows anything that can be converted to a list but that is not otherwise supported directly by the xmlrpclib module already to be marshalled as an XML-RPC array if the allow_iter parameter to the ServerProxy constructor evaluated to true. This includes sets and arrays. Motivation... 1. Python already overloads the XML-RPC array type with both lists and tuples. This just extends that overloading to other currently unsupported Python types which can be converted to lists. Why should lists and tuples have all the fun? 2. Providing transparent conversion to XML-RPC arrays keeps calling code a bit cleaner. One of the attractions of XML-RPC is that the remote procedure call looks identical to a local call. This is especially true in Python because of /F's excellent little _Method class. Clearly as a programmer I could type: import array a = array.array('i', [1, 2,3]) ... from somemodule import somefunction print somefunction(list(a)) but that reveals details of the implementation of somefunction, namely that it can't handle arrays directly, even though in most respects arrays and lists are interchangeable. Attached is a patch for the xmlrpclib library that implements this feature, including minor doc changes and a new test case. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-05 22:23 Message: Logged In: YES user_id=44345 Oh, I forgot my original use case. I was constructing a list of musicians from a larger data structure and used a set to guarantee uniqueness during construction. I didn't really care about element ordering. I either had to convert the set to a list when calling the local function that made the RPC call, or modify the local function to always convert that arg to a list. Both alternatives seemed unattractive to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1374063&group_id=5470 From noreply at sourceforge.net Tue Dec 6 19:26:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 10:26:52 -0800 Subject: [Patches] [ python-Patches-1373762 ] Tweak pprint.PrettyPrinter.format for subclassing Message-ID: Patches item #1373762, was opened at 2005-12-05 11:21 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tweak pprint.PrettyPrinter.format for subclassing Initial Comment: The current format() method doesn't recursively apply an overridden format() method when the width of the object is too short. This patch is designed to remove that limitation and allow a pprint.PrettyPrinter sublcass that could, for example, print all ints and longs in hex: class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] The attached file contains "svn diff --diff-cmd diff - x -b Lib/pprint.py". ---------------------------------------------------------------------- >Comment By: Mark Hirota (markhirota) Date: 2005-12-06 10:26 Message: Logged In: YES user_id=1375527 I agree that while the example use case may not be interesting to you, it certainly has practical use when dealing with hexidecimal values all day long. Also, the change should benefit others looking to get more out of the pprint module. I've attached a 2nd diff file that hopefully should be more useful. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-12-05 12:48 Message: Logged In: YES user_id=3066 Heh, reading the diff alone doesn't help me; there's no helpful context. While the example use case doesn't seem interesting, I consider non-support of sub-class overriding the format() method to be a bug. I'll try and look at the patch more seriously soon, but I've not managed to eek out many tuits lately, and this week is as massively overbooked as any these days. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-05 11:42 Message: Logged In: YES user_id=80475 I don't find the use case to be even slightly motivating. Fred, what do you think of the patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1373762&group_id=5470 From noreply at sourceforge.net Wed Dec 7 04:50:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Dec 2005 19:50:53 -0800 Subject: [Patches] [ python-Patches-1375011 ] Improper handling of duplicate cookies Message-ID: Patches item #1375011, was opened at 2005-12-06 18: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=1375011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Improper handling of duplicate cookies Initial Comment: This patch implements part of bug 1372650. Sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs listed here: http://wp.netscape.com/newsref/std/cookie_spec.html state that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. This patch changes Cookie.py to only use the first instance of duplicate cookies when parsing cookie strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375011&group_id=5470 From noreply at sourceforge.net Wed Dec 7 16:33:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 07:33:41 -0800 Subject: [Patches] [ python-Patches-1375417 ] LibRef: reworked chapter organization Message-ID: Patches item #1375417, was opened at 2005-12-07 10:31 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: LibRef: reworked chapter organization Initial Comment: The attached patch is a first cut at reorganizing the chapters of the Library Reference. Three chapters are currently very large: "Miscellaneous Services", 'Generic OS Services' and 'Optional OS Services'. These chapters are broken up into smaller and more focused chapters such as 'file system services' and 'interprocess communication'. This patch isn't ready to be applied yet; I want feedback on the chapter organization before finishing it. Still to do: * Write introductory paragraphs for all of the new chapters * Re-order chapters roughly by importance; this patch creates them in a random order. Difficult corner cases: where should the logging, itertools, functional modules go? The patch leaves them in 'Miscellaneous'. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-07 10:33 Message: Logged In: YES user_id=11375 Attaching a copy of the modified lib.tex file; it's probably easier to figure out the new organization by reading this file than by reading the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 From noreply at sourceforge.net Wed Dec 7 16:31:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 07:31:52 -0800 Subject: [Patches] [ python-Patches-1375417 ] LibRef: reworked chapter organization Message-ID: Patches item #1375417, was opened at 2005-12-07 10:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: LibRef: reworked chapter organization Initial Comment: The attached patch is a first cut at reorganizing the chapters of the Library Reference. Three chapters are currently very large: "Miscellaneous Services", 'Generic OS Services' and 'Optional OS Services'. These chapters are broken up into smaller and more focused chapters such as 'file system services' and 'interprocess communication'. This patch isn't ready to be applied yet; I want feedback on the chapter organization before finishing it. Still to do: * Write introductory paragraphs for all of the new chapters * Re-order chapters roughly by importance; this patch creates them in a random order. Difficult corner cases: where should the logging, itertools, functional modules go? The patch leaves them in 'Miscellaneous'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 From noreply at sourceforge.net Wed Dec 7 23:37:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 14:37:07 -0800 Subject: [Patches] [ python-Patches-1375417 ] LibRef: reworked chapter organization Message-ID: Patches item #1375417, was opened at 2005-12-07 07:31 Message generated for change (Comment added) made by spencermah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: LibRef: reworked chapter organization Initial Comment: The attached patch is a first cut at reorganizing the chapters of the Library Reference. Three chapters are currently very large: "Miscellaneous Services", 'Generic OS Services' and 'Optional OS Services'. These chapters are broken up into smaller and more focused chapters such as 'file system services' and 'interprocess communication'. This patch isn't ready to be applied yet; I want feedback on the chapter organization before finishing it. Still to do: * Write introductory paragraphs for all of the new chapters * Re-order chapters roughly by importance; this patch creates them in a random order. Difficult corner cases: where should the logging, itertools, functional modules go? The patch leaves them in 'Miscellaneous'. ---------------------------------------------------------------------- Comment By: MIchael Spencer (spencermah) Date: 2005-12-07 14:37 Message: Logged In: YES user_id=1399606 I tried a further re-organization. Results at: http://groups.google.com/group/comp.lang.python/msg/4220f6896602c03c?hl=en& ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-07 07:33 Message: Logged In: YES user_id=11375 Attaching a copy of the modified lib.tex file; it's probably easier to figure out the new organization by reading this file than by reading the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 From noreply at sourceforge.net Thu Dec 8 00:47:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Dec 2005 15:47:20 -0800 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 09:58 Message generated for change (Comment added) made by stroeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-08 00:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 12:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 10:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 10:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 10:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Thu Dec 8 14:22:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 05:22:05 -0800 Subject: [Patches] [ python-Patches-1215184 ] two fileinput enhancements (fileno, openhook) Message-ID: Patches item #1215184, was opened at 2005-06-05 16:52 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1215184&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: two fileinput enhancements (fileno, openhook) Initial Comment: These two patches enhance the fileinput module. The fileno patch adds a "fileno()" method that returns the current file number. The openhook patch adds a possibility to specify an opening hook, that is, instead of calling open(), the hook is called. This is useful, for example, for transparently decompressing gzip files, as wished in RFE #563141. Docs and tests will be added if this is welcomed. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-08 14:22 Message: Logged In: YES user_id=1188172 Second patch attached, sorry ;) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 18:01 Message: Logged In: YES user_id=261020 I don't see any attached openhook patch. The fileno patch looks fine, but personally I would indeed welcome docs and tests :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1215184&group_id=5470 From noreply at sourceforge.net Thu Dec 8 15:14:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 06:14:50 -0800 Subject: [Patches] [ python-Patches-1376309 ] subprocess.CalledProcessError uses errno incorrectly Message-ID: Patches item #1376309, was opened at 2005-12-08 14: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=1376309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376309&group_id=5470 From noreply at sourceforge.net Thu Dec 8 15:27:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 06:27:11 -0800 Subject: [Patches] [ python-Patches-1376309 ] subprocess.CalledProcessError uses errno incorrectly Message-ID: Patches item #1376309, was opened at 2005-12-08 14:14 Message generated for change (Comment added) made by hoffmanm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.CalledProcessError uses errno incorrectly Initial Comment: I have some code which uses subprocess.check_call(), which is buried in other code that catches an OSError, and does different things depending on OSError.errno. Since subprocess.CalledProcessError overloads errno for its own return code values, this leads to confusing error messages. The return code is NOT an errno, and I do not think this field should be overloaded in this way. Additionally, since OSError exceptions generally have an errno attribute set, and exception-handling code expects this, I do not think that CalledProcessError should subclass from it. ---------------------------------------------------------------------- >Comment By: Michael Hoffman (hoffmanm) Date: 2005-12-08 14:27 Message: Logged In: YES user_id=987664 Ugh, this was supposed to be a bug, not a patch. Is there anyway to change this or should I just resumbit? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376309&group_id=5470 From noreply at sourceforge.net Thu Dec 8 15:43:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 06:43:21 -0800 Subject: [Patches] [ python-Patches-1375417 ] LibRef: reworked chapter organization Message-ID: Patches item #1375417, was opened at 2005-12-07 10:31 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: LibRef: reworked chapter organization Initial Comment: The attached patch is a first cut at reorganizing the chapters of the Library Reference. Three chapters are currently very large: "Miscellaneous Services", 'Generic OS Services' and 'Optional OS Services'. These chapters are broken up into smaller and more focused chapters such as 'file system services' and 'interprocess communication'. This patch isn't ready to be applied yet; I want feedback on the chapter organization before finishing it. Still to do: * Write introductory paragraphs for all of the new chapters * Re-order chapters roughly by importance; this patch creates them in a random order. Difficult corner cases: where should the logging, itertools, functional modules go? The patch leaves them in 'Miscellaneous'. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 09:43 Message: Logged In: YES user_id=11375 Attaching a copy of Michael Spencer's reorganization ---------------------------------------------------------------------- Comment By: MIchael Spencer (spencermah) Date: 2005-12-07 17:37 Message: Logged In: YES user_id=1399606 I tried a further re-organization. Results at: http://groups.google.com/group/comp.lang.python/msg/4220f6896602c03c?hl=en& ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-07 10:33 Message: Logged In: YES user_id=11375 Attaching a copy of the modified lib.tex file; it's probably easier to figure out the new organization by reading this file than by reading the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 From noreply at sourceforge.net Thu Dec 8 16:16:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 07:16:11 -0800 Subject: [Patches] [ python-Patches-1376361 ] Use 'seealso' to add examples to LibRef Message-ID: Patches item #1376361, was opened at 2005-12-08 10: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=1376361&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Use 'seealso' to add examples to LibRef Initial Comment: Fredrik Lundh suggested a simple markup to let people publish examples on their own sites and have the examples get linked into the Library Reference. I wrote a simple parser for the markup and checked it in as sandbox/seealso. The attached patch adds a Makefile target, 'examples', that downloads feeds listed in a file and generates a directory of *.tex files that can be included. The patch also modifies one file, libzlib.tex, to include the generated examples; all of the modules would need to be modified. The patch currently assumes that you've checked out the sandbox in the same directory as your Python tree. If accepted, the seealso scripts would move into Doc/tools/. The Makefile patch makes lib/ always trigger the examples target. Alternatively it could be left as a separate target; as long as the release process includes "make examples", it would be fine. (I can't figure out the shell-script hackery to only update the examples every 24 hours. The Python scripts could be modified to do this.) Running "make examples" requires a file called Doc/example-feeds. Currently my copy contains a single line: 'file:../../sandbox/seealso/seealso.xml'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376361&group_id=5470 From noreply at sourceforge.net Fri Dec 9 00:47:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 15:47:37 -0800 Subject: [Patches] [ python-Patches-1372125 ] fix UnixBrowswer failure when no browser running Message-ID: Patches item #1372125, was opened at 2005-12-02 18:04 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372125&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: fix UnixBrowswer failure when no browser running Initial Comment: See discussions in bug #1352621 and bug #1338995 for even more details. Background: The webbrowser.py was modified, post-Python 2.4.2, to tell whether or not the browser invocation succeeded or not. Unfortunately, the modifications caused Python applications to hang when no browser was already present. And the reputed fix for bug #1338995, revision 41419, only made things worse for UnixBrowsers. Fix: The changes to webbrowser.py were well intentioned, but failed because it was difficult to tell if invocation succeeded due to an extra level of indirection in invoking the browser by using os.system(). The attached patch, for revision 41511, uses subprocess.Popen() instead for UnixBrowser. The other uses of os.system() would also benefit, but are less critical to me. ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-12-08 15:47 Message: Logged In: YES user_id=131838 Replace original patch with one that has the tabs expanded out into spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1372125&group_id=5470 From noreply at sourceforge.net Fri Dec 9 07:16:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Dec 2005 22:16:33 -0800 Subject: [Patches] [ python-Patches-1376914 ] fix description of format_exc in traceback doc Message-ID: Patches item #1376914, was opened at 2005-12-08 22: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=1376914&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: fix description of format_exc in traceback doc Initial Comment: traceback.format_exc() docs erroneously mentioned file argument ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376914&group_id=5470 From noreply at sourceforge.net Fri Dec 9 18:04:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Dec 2005 09:04:11 -0800 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 22:25 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Fredrik Lundh (effbot) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2005-12-09 11:04 Message: Logged In: YES user_id=555 This patch seems to have been stalled now for over a year. Could it be applied? Or, alternatively, could someone provide some sort of reason why it shouldn't be? Thanks. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 17:53 Message: Logged In: YES user_id=80475 Fred, what do you think of the proposal. Are the backwards compatability issues worth it? ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 15:15 Message: Logged In: YES user_id=555 Apparently this patch is stalled, but I'd like to get it in, in some form, for 2.4. The only question, as far as I know, is whether empty matches following non-empty matches "count" or not (they do in the original patch). If I make a patch with the "doesn't count" behavior, could we apply that right away? I'd rather get either behavior in for 2.4 than wait for 2.5... ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-28 11:23 Message: Logged In: YES user_id=555 I picked through CVS, python-dev and google and came up with this. The current behavior was present way back in the earliest regsub.py in CVS (dated Sep 1992); subsequent implementation seem to be mirroring this behavior. The CVS comment back in 1992 described split as modeled on nawk. A check of nawk(1) confirms that nawk only splits on non-null matches. Perl (circa 5.6) on the other hand, appears to split the way this patch does (though I wasn't aware of that when I wrote the patch) so that might argue in the other direction. I would note, too, that re.findall and re.finditer tend in this direction ("Empty matches are included in the result unless they touch the beginning of another match."). The python-dev archive doesn't seem to go back far enough to be relevant and I'm not sure how to search it. General googling (python "re.split" empty match) found a few hits. Probably the most relevant is Tim Peters saying "Python won't change here (IMO)" and giving the example that he also gives in a comment to bug #852532 (which this patch addresses). He also wonders in his comment about the possibility of a "design constraint", but I think this patch addresses that concern. As far as I can tell, the current behavior was a design decision made over 10 years ago, between two alternatives that probably didn't matter much at the time. Skipping empty matches probably seemed harmless before lookahead/lookbehind assertions. Now, though, the current behavior seems like a significant hindrance. Furthermore, it ought to be pretty trivial to modify any existing patterns to get the old behavior, should that be desired (e.g., use 'x+' instead of 'x*'). (I didn't notice that re.findall doc when I originally wrote this patch. Perhaps the doc in the patch should be slightly modified to help emphasize the similarity between how re.findall and re.split handle empty matches.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-27 09:08 Message: Logged In: YES user_id=11375 Overall I like the patch and wouldn't mind seeing the change become the default behaviour. However, I'm nervous about possibly not understanding the reason the prohibition on zero-length matches was added in the first place. Can you please do some research in the CVS logs and python-dev archives to figure out why the limitation was implemented in the first place? ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 07:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Fri Dec 9 20:22:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Dec 2005 11:22:53 -0800 Subject: [Patches] [ python-Patches-1376361 ] Use 'seealso' to add examples to LibRef Message-ID: Patches item #1376361, was opened at 2005-12-08 10:16 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376361&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Use 'seealso' to add examples to LibRef Initial Comment: Fredrik Lundh suggested a simple markup to let people publish examples on their own sites and have the examples get linked into the Library Reference. I wrote a simple parser for the markup and checked it in as sandbox/seealso. The attached patch adds a Makefile target, 'examples', that downloads feeds listed in a file and generates a directory of *.tex files that can be included. The patch also modifies one file, libzlib.tex, to include the generated examples; all of the modules would need to be modified. The patch currently assumes that you've checked out the sandbox in the same directory as your Python tree. If accepted, the seealso scripts would move into Doc/tools/. The Makefile patch makes lib/ always trigger the examples target. Alternatively it could be left as a separate target; as long as the release process includes "make examples", it would be fine. (I can't figure out the shell-script hackery to only update the examples every 24 hours. The Python scripts could be modified to do this.) Running "make examples" requires a file called Doc/example-feeds. Currently my copy contains a single line: 'file:../../sandbox/seealso/seealso.xml'. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-09 14:22 Message: Logged In: YES user_id=11375 LaTeX supports \InputIfFileExists{examples/zlib.tex}{}{}. LaTeX2HTML chokes on \InputIfFileExists, however; some hackery will be required. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376361&group_id=5470 From noreply at sourceforge.net Sat Dec 10 18:19:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 09:19:38 -0800 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-19 04:09 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-12-11 03:19 Message: Logged In: YES user_id=1038590 New patch worked fine on Ubuntu 5.10 (all tests in 'make test' passed, aside from the skips due to the various extension modules I can't build) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-06 08:17 Message: Logged In: YES user_id=6656 Here's a patch updated to SVN HEAD (the PEP 342 implementation meant this wasn't quite trivial). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-16 05:37 Message: Logged In: YES user_id=6656 > Is it worth adding a comment on parsing precedence? I've been studiously avoiding thinking about that :) > Making something both an instance and a subclass of > anything besides object might be weird enough that you > don't *want* to document the results yet. Quite. What happens, happens IMHO. I'm prepared to be argued into a different position on this, but I do think the only reason someone would do this is curiousity :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-16 03:51 Message: Logged In: YES user_id=764593 Is it worth adding a comment on parsing precedence? An object can be both an instance and a class, which puts some ambiguity between "raise class" and "raise classinstance". Assuming the class seems sensible; I'm just wondering whether it should be made explicit. (Making something both an instance and a subclass of anything besides object might be weird enough that you don't *want* to document the results yet.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-16 03:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-16 03:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-16 02:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-16 02:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-16 01:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-10 00:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 23:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-19 05:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Sat Dec 10 18:45:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 09:45:26 -0800 Subject: [Patches] [ python-Patches-1276356 ] Adding new regrtest resource 'urlfetch' Message-ID: Patches item #1276356, was opened at 2005-08-30 16:05 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Adding new regrtest resource 'urlfetch' Initial Comment: This is a fix for SF #1010952. test_normalization and test_codecmaps_* require too much effort to fetch the each test files. When this fix got applied, passing '-uurlfetch' to regrtest will enables on-demand downloads for the tests. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-11 02:45 Message: Logged In: YES user_id=55188 Committed as r41637. Thank you for the reviews! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-10-06 13:14 Message: Logged In: YES user_id=55188 I thought this needs to give notification when it's downloading files as birkenfeld suggested. I'll commit this fix after implementing that. Thank you for comments! :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 14:57 Message: Logged In: YES user_id=33168 Perky, why don't you check this in? I don't see a particular problem with the code. If it breaks something, we oughta find out soon enough. :-) ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 06:07 Message: Logged In: YES user_id=1188172 Applied the patch, works like a charm. I wonder though if you should give the user some feedback when he is downloading a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1276356&group_id=5470 From noreply at sourceforge.net Sat Dec 10 21:40:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Dec 2005 12:40:44 -0800 Subject: [Patches] [ python-Patches-1377848 ] xml.parsers.expat documentation fix Message-ID: Patches item #1377848, was opened at 2005-12-10 22: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=1377848&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: xml.parsers.expat documentation fix Initial Comment: The included patch fixes a typo for the overridable StartCdataSectionHandler func. Doc location: Doc/lib/libpyexpat.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1377848&group_id=5470 From noreply at sourceforge.net Mon Dec 12 18:00:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 09:00:47 -0800 Subject: [Patches] [ python-Patches-1104669 ] new-style exceptions Message-ID: Patches item #1104669, was opened at 2005-01-18 13:09 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: new-style exceptions Initial Comment: This patch allows new-style exceptions and makes Exception a new-style class. The test suite runs, apart from failures in test_tempfile (will dig, but doubt this is my fault) and test__locale (known OS X problem). ---------------------------------------------------------------------- >Comment By: Michael Chermside (mcherm) Date: 2005-12-12 12:00 Message: Logged In: YES user_id=99874 I haven't tried out the patch, I just want to chime in to say how VERY much I would like to have this. I'm ready NOW to completely give up using old-style classes, but because of exceptions I'm not allowed to. This would fix that for me. If Python had a "vote for your favorite bugs" list, I'd be voting for this one. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-12-10 12:19 Message: Logged In: YES user_id=1038590 New patch worked fine on Ubuntu 5.10 (all tests in 'make test' passed, aside from the skips due to the various extension modules I can't build) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-05 17:17 Message: Logged In: YES user_id=6656 Here's a patch updated to SVN HEAD (the PEP 342 implementation meant this wasn't quite trivial). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 14:37 Message: Logged In: YES user_id=6656 > Is it worth adding a comment on parsing precedence? I've been studiously avoiding thinking about that :) > Making something both an instance and a subclass of > anything besides object might be weird enough that you > don't *want* to document the results yet. Quite. What happens, happens IMHO. I'm prepared to be argued into a different position on this, but I do think the only reason someone would do this is curiousity :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:51 Message: Logged In: YES user_id=764593 Is it worth adding a comment on parsing precedence? An object can be both an instance and a class, which puts some ambiguity between "raise class" and "raise classinstance". Assuming the class seems sensible; I'm just wondering whether it should be made explicit. (Making something both an instance and a subclass of anything besides object might be weird enough that you don't *want* to document the results yet.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 12:39 Message: Logged In: YES user_id=6656 Jim: Yes. It looks like I ran delete-trailing-whitespace on the file at some point. I could redo the diff without them, but it would be tedious... Tim: thanks! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-15 12:34 Message: Logged In: YES user_id=764593 Several lines near the end of errors.c had no visible change. Was this a whitespace cleanup, or is this a risk of tab/space mixing? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:17 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-15 11:03 Message: Logged In: YES user_id=31435 FYI, there's nothing special about PicklingError in the pickletools doctest, it's just aiming at an example of an instance -- that it's also an exception instance is irrelevant to what the test is aiming at. Tell you what: I'll check in a suitable change to pickletools.py, so that the example it uses stops interfering with this patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-15 10:40 Message: Logged In: YES user_id=6656 I found the final wart (caught by test_tempfile of all things). I think the attached is good to go. Issues remaining: test_pickletools fails, because PickleError is now new- style and thus pickles differently. Docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-02-09 09:18 Message: Logged In: YES user_id=6656 New patch attached. Did this a while ago, don't actually remember the details of what's new :-/ The problem with the previous patch was that one of my exception- checking macros had the side-effect of clearing any pending exception... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-01-19 08:25 Message: Logged In: YES user_id=6656 You're right! Odd. No time to fix it today, I'm afraid. ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2005-01-18 14:47 Message: Logged In: YES user_id=329382 One thing: Raising an old-style class/instance doesn't give a traceback or populate sys.last_*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1104669&group_id=5470 From noreply at sourceforge.net Mon Dec 12 22:34:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Dec 2005 13:34:22 -0800 Subject: [Patches] [ python-Patches-1379023 ] weakref callbacks are called only if the weakref is alive Message-ID: Patches item #1379023, was opened at 2005-12-12 23:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: weakref callbacks are called only if the weakref is alive Initial Comment: Weak reference objects have an optional callback argument, which is a function that is called when the original object is killed. This function is called only if the created weakref object is still alive. This fact isn't mentioned in the documentation - this patch mentions it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379023&group_id=5470 From noreply at sourceforge.net Tue Dec 13 09:54:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 00:54:29 -0800 Subject: [Patches] [ python-Patches-1379332 ] StreamReader.readline with size reading multiple lines Message-ID: Patches item #1379332, was opened at 2005-12-13 01: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=1379332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader.readline with size reading multiple lines Initial Comment: In Python 2.4.2 and trunk, when StreamReader.readline is used with a size argument, it will eventually truncate some lines, even if every line is less than the size. It works correctly in Python 2.3.5, I haven't tried other versions. >>> f=codecs.getreader('ascii')(StringIO.StringIO("hello\nworld\n")) >>> f.readline(8) u'hello\n' >>> f.readline(8) u'wo' >>> f.readline(8) u'rld\n' I've attached a patch which fixes this and modifies test_codecs.py to test this. I don't know if this is the best way to fix it, but I didn't want to make deeper changes to the caching mechanism, being unfamiliar with this code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 From noreply at sourceforge.net Tue Dec 13 12:09:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 03:09:04 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 22:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-13 11:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 21:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 19:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Tue Dec 13 17:47:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 08:47:55 -0800 Subject: [Patches] [ python-Patches-1349118 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349118, was opened at 2005-11-05 12:05 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-13 11:47 Message: Logged In: YES user_id=6380 The patch looks good as a fix for bug 495682. I don't see which lines in the patch warrant the claim "solves tracebacks if proxy is specified for a protocol where no proxy is currently supported" -- can you explain this? I'd like you to request validation (testing) from someone else on python-dev who can actually run this code -- I have no way to verify that it works as advertised. ---------------------------------------------------------------------- Comment By: Johannes Nicolai (jonico) Date: 2005-11-07 05:27 Message: Logged In: YES user_id=863272 Perhaps some words about the accuracy of the patch: I have successfully tested it with squid 2.5 and squid 3.0 as http and https proxy with and without password. I used the integrated test routines in urllib.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 From noreply at sourceforge.net Tue Dec 13 18:30:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Dec 2005 09:30:03 -0800 Subject: [Patches] [ python-Patches-1349118 ] Patch f. bug 495682 cannot handle http_proxy with user:pass@ Message-ID: Patches item #1349118, was opened at 2005-11-05 18:05 Message generated for change (Comment added) made by jonico You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Nicolai (jonico) Assigned to: Nobody/Anonymous (nobody) Summary: Patch f. bug 495682 cannot handle http_proxy with user:pass@ Initial Comment: solves problems for http and https proxies described in this bug solves tracebacks if proxy is specified for a protocol where no proxy is currently supported added dynamic proxy authentification for http and https solved bug that if a host accessed by the https protocol requires authentification, the https proxy won't be used after questioning the password ---------------------------------------------------------------------- >Comment By: Johannes Nicolai (jonico) Date: 2005-12-13 18:30 Message: Logged In: YES user_id=863272 Sorry, I have only uploaded an old version of the patch. There, the traceback problem was not solved at all 8-) I have now added the complete patch, that already relates to the newest version in the subversion repository. I will try to get another tester for my code, but it might be difficult. Unfortunately, only few people have an SSL capable proxy. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-13 17:47 Message: Logged In: YES user_id=6380 The patch looks good as a fix for bug 495682. I don't see which lines in the patch warrant the claim "solves tracebacks if proxy is specified for a protocol where no proxy is currently supported" -- can you explain this? I'd like you to request validation (testing) from someone else on python-dev who can actually run this code -- I have no way to verify that it works as advertised. ---------------------------------------------------------------------- Comment By: Johannes Nicolai (jonico) Date: 2005-11-07 11:27 Message: Logged In: YES user_id=863272 Perhaps some words about the accuracy of the patch: I have successfully tested it with squid 2.5 and squid 3.0 as http and https proxy with and without password. I used the integrated test routines in urllib.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1349118&group_id=5470 From noreply at sourceforge.net Wed Dec 14 14:11:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 05:11:35 -0800 Subject: [Patches] [ python-Patches-1153056 ] PyXxx_Check() speed-up Message-ID: Patches item #1153056, was opened at 2005-02-27 21:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check() speed-up Initial Comment: Once upon a time, the macros PyInt_Check(), PyString_Check(), etc., used to be very fast: just a pointer comparison. But 2.2 came. Suddenly, types could inherit from each other. Thus the macros became: (ob->type == &PyXxx_Check || PyType_IsSubType(ob->type, &PyXxx_Check) Subtyping of built-in types still being rare, the common cases here are: (1) ob is indeed exactly of type Xxx, (2) ob is absolutely not an instance of Xxx. The macro is fast for case 1 but becomes a call to a slow function in case 2. It sounds minor -- but a program can make half a million "case 2" calls in 5 seconds. The following patch proposes to fix that, based on a few measurements that show which are the more common "case 2" calls in a few applications. It adds a family of type flags meaning "this type is not at all an Xxx", for Xxx in [module, tuple, float, int, unicode, long, complex, str]. I cannot measure the performance gain on this machine (figures vary all the time) but it looks like some 0.2s for the above-mentioned 5s program. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=4771 I measured the performance gain more precisely. On a couple of modern Pentium 4s it makes no difference at all. On my old laptop (Pentium III 700Mhz) results are a bit inconsistent. As usual, Pystone shows speed-ups but not really anything else. So I'm just closing this. For reference I attach the patch updated to the svn head. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-05-08 23:26 Message: Logged In: YES user_id=51702 With pystone.py I could measure a speedup of atleast 1000 pystones. From 36764 stones without the patch to 38461 with the patch. Granted, I didn't test very scientifically but the speedup is noticeable. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-14 13:48 Message: Logged In: YES user_id=4771 There might be problems with types that don't go through PyType_Ready(). We can't just compute the correct flags in there and do a single bit test in PyXxx_Check(), as far as I can see. Hence the idea to add the flag to a type only when it is dynamically found not to be a subtype of the given base type. I can't think of anything bad happening because of this mutation... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 10:57 Message: Logged In: YES user_id=6656 I suppose I should read the patch then :) It seems very odd that _PyType_FastTypeCheck mutates a->tp_flags. In fact, shoudn't it be possible to not have _PyType_FastTypeCheck at all? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-14 09:22 Message: Logged In: YES user_id=4771 I am convinced now by #1153075 that PyCheck_Xxx should not be semantically changed, and really means walking the mro. So the patch here remains valid. Yes, I know that N is unbounded, that's why the next sentence was "let's only include the most common of them". Where to stop? Don't guess, measure. That's what I did, and in a few applications there were systematically a set of types that were PyChecked quite more often than the others. So my patch special-cases exactly these types. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-14 08:05 Message: Logged In: YES user_id=6656 (I haven't seen any mail about this patch!) > array of N bits, where N is the number of C-level PyXxxObject > structures That's unbounded too, in the presence of extension modules. (I still think my fix for #1153075 suffices, and is probably a good thing). I can believe that special casing int and str subclasses is worth it -- but where to stop? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-28 09:26 Message: Logged In: YES user_id=4771 Ah, but that's not so different: M can still be arbitrarily large... However, see also bug #1153075. I think that PyInt_Check() using PyType_IsSubtype() is essentially buggy: the purpose of PyInt_Check() is to check if the PyObject* is a PyIntObject*, not if its type pretends to have 'int' in its mro. If we fix this, then making PyType_IsSubtype() faster will become unrelated to making PyXxx_Check() faster. If we want to fix PyXxx_Check() for the bug described above and make it fast too, then we probably only need an array of N bits, where N is the number of C-level PyXxxObject structures. The idea of only including the most common such structures instead of all of them was based on simplicity and performance (it's faster and easier to check for a known bit than for a bit which itself is computed at run-time). If we want to make PyType_IsSubtype() fast, it might be worth the effort or not; we should measure it. But I think it's unrelated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-28 06:20 Message: Logged In: YES user_id=21627 No. Each type would have an array of M bits, where M is the maximum number of a super class; each type would also store the value of M. As types are created and deleted dynamically, it might be necessary to keep track of assigned type numbers, and recycle them as types are deleted. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-27 23:56 Message: Logged In: YES user_id=4771 I'm not sure I understand your suggestion. Would each type have an array of N bits, where N is the total number of types that exist? That looks quite unreasonable in any program that builds a lot of types (I know some that build them programatically in loops). What I did is a limited version of that: a bitfield with room for only some commonly checked-for superclasses. (With some care, my patch could be modified to build the bitfield in PyType_Ready(); this would allow the PyXxx_Check() macros to become a single bit check operation.) Changing the base classes isn't an issue in my limited patch because you cannot ever add or remove the core built-in types I check for from the bases of an existing type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-27 23:44 Message: Logged In: YES user_id=21627 I would rather see a constant-time subtype check implemented in Python, using strategies that other interpreters have been using for a long time. Essentially, each type gets a unique number (e.g. in the order of PyType_Ready calls), and a bit-field of all supertypes, with a bit set for each type that is one of its supertypes. Creation of the bitfield could be delayed until a subtype check is actually needed. The tricky part is to update the supertype bitmask when __super__ is assigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1153056&group_id=5470 From noreply at sourceforge.net Wed Dec 14 18:11:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 09:11:11 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Wed Dec 14 18:40:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 09:40:05 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 22:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 17:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 17:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 11:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 21:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 19:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Wed Dec 14 20:11:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 11:11:51 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 11:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Wed Dec 14 21:06:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 12:06:10 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 22:22 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-14 20:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 19:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 17:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 17:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 11:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 21:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 19:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Wed Dec 14 21:25:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 12:25:24 -0800 Subject: [Patches] [ python-Patches-1380777 ] Some fixes for the binary distribution builder Message-ID: Patches item #1380777, was opened at 2005-12-14 21: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=1380777&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Some fixes for the binary distribution builder Initial Comment: The attached patch fixes some problems with the build script for binary distributions on Mac OS X 1) the builder used to unconditionally replace parts of Apple's python installation. This is needed on OSX 10.3, but not on later versions. 2) corrects version numbers in several places, and verifies the correct version in the build script 3) the builddocs script usually crashes on my system after correctly building the documentation, workaround this in the build script 4) Some hacks w.r.t. a pyconfig.h file that works on 10.3 and 10.4 (see below) There is a problem with pyconfig.h in a binary distribution on OSX: there are some header file regressions between 10.3 and 10.4. This means that you cannot build extensions with a python that was build on 10.3 while running on 10.4 (unless you're lucky). My first workaround was a pyconfig.h that #include-d pyconfig-10.3.h or pyconfig-10.4.h after testing the current platform (by misusing some feature macros in AvailabilityMacros.h). This doesn't work because distutils reads pyconfig.h and makes that available to setup.py authors. A second, untested approach is to merge the two pyconfig.h files. I guess it would be good enough to just surpress the #defines for _POSIX_SOURCE, _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED on Tiger. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 From noreply at sourceforge.net Wed Dec 14 21:55:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 12:55:16 -0800 Subject: [Patches] [ python-Patches-1380777 ] Some fixes for the binary distribution builder Message-ID: Patches item #1380777, was opened at 2005-12-14 21:25 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 Please note that this 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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Some fixes for the binary distribution builder Initial Comment: The attached patch fixes some problems with the build script for binary distributions on Mac OS X 1) the builder used to unconditionally replace parts of Apple's python installation. This is needed on OSX 10.3, but not on later versions. 2) corrects version numbers in several places, and verifies the correct version in the build script 3) the builddocs script usually crashes on my system after correctly building the documentation, workaround this in the build script 4) Some hacks w.r.t. a pyconfig.h file that works on 10.3 and 10.4 (see below) There is a problem with pyconfig.h in a binary distribution on OSX: there are some header file regressions between 10.3 and 10.4. This means that you cannot build extensions with a python that was build on 10.3 while running on 10.4 (unless you're lucky). My first workaround was a pyconfig.h that #include-d pyconfig-10.3.h or pyconfig-10.4.h after testing the current platform (by misusing some feature macros in AvailabilityMacros.h). This doesn't work because distutils reads pyconfig.h and makes that available to setup.py authors. A second, untested approach is to merge the two pyconfig.h files. I guess it would be good enough to just surpress the #defines for _POSIX_SOURCE, _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED on Tiger. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-12-14 21:55 Message: Logged In: YES user_id=580910 I'm currently testing the obvious (in hindsight) solution for my pyconfig.h problems: $ diff -u Python-2.4.2-orig/configure.in Python-2.4.2/configure.in --- Python-2.4.2-orig/configure.in Sun Aug 7 23:08:53 2005 +++ Python-2.4.2/configure.in Wed Dec 14 21:41:32 2005 @@ -173,7 +173,7 @@ ;; # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE # disables platform specific features beyond repair. - Darwin/8.*) + Darwin/8.*|Darwin/7.*) define_xopen_source=no ;; That is, tell configure not to bother trying _POSIX_SOURCE on Darwin 7.x (aka Panther). So far this doesn't seem to cause regressions, but I haven't run the tests yet nor did I perform a full comparison between this build and a build without the patch above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380777&group_id=5470 From noreply at sourceforge.net Thu Dec 15 00:14:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 15:14:53 -0800 Subject: [Patches] [ python-Patches-1380952 ] Fix bug read() would hang on ssl socket if settimeout() used Message-ID: Patches item #1380952, was opened at 2005-12-15 00: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=1380952&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bug read() would hang on ssl socket if settimeout() used Initial Comment: The problem has occured many times before like bugs https://sourceforge.net/tracker/?group_id=5470&atid= 105470&func=detail&aid=1353269 https://sourceforge.net/tracker/?group_id=5470&atid= 105470&func=detail&aid=977680 https://sourceforge.net/tracker/index.php?func=detail& aid=1098618&group_id=5470&atid=105470 This also fixes this bug: https://sourceforge.net/tracker/index.php?func=detail& aid=1166206&group_id=5470&atid=105470 Example test: import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(30.0) # connect to service which issues an welcome banner (without need to write anything) s.connect(("gmail.org", 995)) ss = socket.ssl(s) # read part of return welcome banner twice,# read part of return welcome banner twice ss.read(1) ss.read(1) s.close() it will cause socket.sslerror: The read operation timed out on the second read() This is because _ssl.so modules doesn't handle SSL reads properly. The problem is in Modules/_ssl.c: PySSL_SSLread() we have: sockstate = check_socket_and_wait_for_timeout (self->Socket, self->ssl, 0); // XXXX HERE XXX if (sockstate == SOCKET_HAS_TIMED_OUT) { PyErr_SetString(PySSLErrorObject, "The read operation timed out"); Py_DECREF(buf); return NULL; } do {.... What will happen if SSL layer already read data and have that data in it's own buffers? The function check_ socket_and_wait_for_timeout() doing select(readfds) will wait forever until timeout occurs. The solution is to use http://www.openssl.org/docs/ssl/SSL_pending. html function. The attached patch fixes the problem and also adds test for python test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380952&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:38:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:38:56 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 23:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 11:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Thu Dec 15 06:46:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 21:46:38 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 14:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 21:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 12:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 09:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 09:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 03:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 13:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 11:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Thu Dec 15 07:16:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 22:16:31 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 14:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 22:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 21:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 12:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 09:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 09:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 03:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 13:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 11:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Thu Dec 15 07:43:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 22:43:39 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 00:43 Message: Logged In: YES user_id=1404983 Neal, thanks for the additional encouragement. The issues I'm worried about with regard to signed/unsigned are on the user code side. In most cases it's a signed format string matching to an unsigned variable, and often is for a positive only value (count or length, or similar). I doubt more than a couple python programs try to use values large enough for it to be relevant (outside of semantically questionable -1 markers), however before arbitrarily changing format strings, I want to be sure such a -1 value parsed with an unsigned format string will not start raising ValueErrors - I want my patch to be a candidate for backporting if desired. Better to leave well enough alone if it's mostly safe. There are also tons of unsigned char * variables passed for string formats; since I don't know why they are explicitly unsigned, and most of Python works as is, I'd rather just leave those alone. It would suck to hit one of the special cases for which it really needs to be an unsigned char *. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 00:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 23:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 23:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 11:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Thu Dec 15 08:04:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 23:04:45 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 14:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 23:04 Message: Logged In: YES user_id=33168 Thanks for your comments. It made a lot more sense after I finished reading your blog. I think the signed-ness issues which relate to ("i", unsigned int) or ("l", unsigned long) should be fixed. I agree with your concern about fixing and backporting, though I don't know how best to address it. I'm not concerned about unsigned vs signed char * for 's' and 't' formats. I don't think they are a big deal which we seem to agree on. I fixed the bltinmodule.c:1910 problem. That wasn't really an issue since the variable was larger and not actually used. The problem with xxmodule.c:207 is in error checking code, so I'm not concerned about that. (It's checking that O# is invalid.) Can you run your script on Objects too? It would be great if we got your script into the python tree too so we can search for these things in the future. (Ideally we would have complete unittests, but I'm not holding my breath for that to happen.) For the record is your name Michael Urman? I would like to add you to the ACKS file. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 22:43 Message: Logged In: YES user_id=1404983 Neal, thanks for the additional encouragement. The issues I'm worried about with regard to signed/unsigned are on the user code side. In most cases it's a signed format string matching to an unsigned variable, and often is for a positive only value (count or length, or similar). I doubt more than a couple python programs try to use values large enough for it to be relevant (outside of semantically questionable -1 markers), however before arbitrarily changing format strings, I want to be sure such a -1 value parsed with an unsigned format string will not start raising ValueErrors - I want my patch to be a candidate for backporting if desired. Better to leave well enough alone if it's mostly safe. There are also tons of unsigned char * variables passed for string formats; since I don't know why they are explicitly unsigned, and most of Python works as is, I'd rather just leave those alone. It would suck to hit one of the special cases for which it really needs to be an unsigned char *. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 22:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 21:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 12:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 09:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 09:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 03:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 13:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 11:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Thu Dec 15 08:40:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Dec 2005 23:40:11 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 01:40 Message: Logged In: YES user_id=1404983 Objects/ is clean on the ParseTuple, and all I see on BuildValue are due to limitations in my script. The script itself is available at http://www.tortall.net/mu/static/fmtcheck.py (linked via the blog entry as well if it moves later), and if GPL terms are useless, I'm willing to consider others. Regardless the script is currently too false-positive happy for automated use (i hope not false-negative happy). I am indeed Michael Urman. I don't know how quickly I'll have a final patch---perhaps by the end of the week---a lot of it is mind-numbing detail work. Feel free to preemptively obsolete parts of the patch as you see fit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 01:04 Message: Logged In: YES user_id=33168 Thanks for your comments. It made a lot more sense after I finished reading your blog. I think the signed-ness issues which relate to ("i", unsigned int) or ("l", unsigned long) should be fixed. I agree with your concern about fixing and backporting, though I don't know how best to address it. I'm not concerned about unsigned vs signed char * for 's' and 't' formats. I don't think they are a big deal which we seem to agree on. I fixed the bltinmodule.c:1910 problem. That wasn't really an issue since the variable was larger and not actually used. The problem with xxmodule.c:207 is in error checking code, so I'm not concerned about that. (It's checking that O# is invalid.) Can you run your script on Objects too? It would be great if we got your script into the python tree too so we can search for these things in the future. (Ideally we would have complete unittests, but I'm not holding my breath for that to happen.) For the record is your name Michael Urman? I would like to add you to the ACKS file. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 00:43 Message: Logged In: YES user_id=1404983 Neal, thanks for the additional encouragement. The issues I'm worried about with regard to signed/unsigned are on the user code side. In most cases it's a signed format string matching to an unsigned variable, and often is for a positive only value (count or length, or similar). I doubt more than a couple python programs try to use values large enough for it to be relevant (outside of semantically questionable -1 markers), however before arbitrarily changing format strings, I want to be sure such a -1 value parsed with an unsigned format string will not start raising ValueErrors - I want my patch to be a candidate for backporting if desired. Better to leave well enough alone if it's mostly safe. There are also tons of unsigned char * variables passed for string formats; since I don't know why they are explicitly unsigned, and most of Python works as is, I'd rather just leave those alone. It would suck to hit one of the special cases for which it really needs to be an unsigned char *. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 00:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 23:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 23:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 11:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Thu Dec 15 10:23:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 01:23:41 -0800 Subject: [Patches] [ python-Patches-1381398 ] bind() for netlink sockets Message-ID: Patches item #1381398, was opened at 2005-12-15 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1381398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Timo Mets?l? (metsala) Assigned to: Nobody/Anonymous (nobody) Summary: bind() for netlink sockets Initial Comment: Support for netlink sockets in Linux (AF_NETLINK) doesn't currently include bind()ing to a local address. The attached patch adds this functionality (local address of a netlink socket consists of process id and/or group bitmask). Example use: def get_bound_nl_sock(netlink_family): net_fd = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW, netlink_family) net_fd.bind((os.getpid(),0)) return net_fd Patch made against Python 2.4.2, tested in Linux 2.4.20-8 (Red Hat 9) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1381398&group_id=5470 From noreply at sourceforge.net Thu Dec 15 18:28:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 09:28:36 -0800 Subject: [Patches] [ python-Patches-1380952 ] Fix bug read() would hang on ssl socket if settimeout() used Message-ID: Patches item #1380952, was opened at 2005-12-15 00:14 Message generated for change (Comment added) made by arekm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380952&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Arkadiusz Miskiewicz (arekm) Assigned to: Nobody/Anonymous (nobody) Summary: Fix bug read() would hang on ssl socket if settimeout() used Initial Comment: The problem has occured many times before like bugs https://sourceforge.net/tracker/?group_id=5470&atid= 105470&func=detail&aid=1353269 https://sourceforge.net/tracker/?group_id=5470&atid= 105470&func=detail&aid=977680 https://sourceforge.net/tracker/index.php?func=detail& aid=1098618&group_id=5470&atid=105470 This also fixes this bug: https://sourceforge.net/tracker/index.php?func=detail& aid=1166206&group_id=5470&atid=105470 Example test: import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(30.0) # connect to service which issues an welcome banner (without need to write anything) s.connect(("gmail.org", 995)) ss = socket.ssl(s) # read part of return welcome banner twice,# read part of return welcome banner twice ss.read(1) ss.read(1) s.close() it will cause socket.sslerror: The read operation timed out on the second read() This is because _ssl.so modules doesn't handle SSL reads properly. The problem is in Modules/_ssl.c: PySSL_SSLread() we have: sockstate = check_socket_and_wait_for_timeout (self->Socket, self->ssl, 0); // XXXX HERE XXX if (sockstate == SOCKET_HAS_TIMED_OUT) { PyErr_SetString(PySSLErrorObject, "The read operation timed out"); Py_DECREF(buf); return NULL; } do {.... What will happen if SSL layer already read data and have that data in it's own buffers? The function check_ socket_and_wait_for_timeout() doing select(readfds) will wait forever until timeout occurs. The solution is to use http://www.openssl.org/docs/ssl/SSL_pending. html function. The attached patch fixes the problem and also adds test for python test suite. ---------------------------------------------------------------------- >Comment By: Arkadiusz Miskiewicz (arekm) Date: 2005-12-15 18:28 Message: Logged In: YES user_id=139606 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1380952&group_id=5470 From noreply at sourceforge.net Fri Dec 16 02:57:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 17:57:27 -0800 Subject: [Patches] [ python-Patches-1382087 ] list.count() patch for feature request 1370948 Message-ID: Patches item #1382087, was opened at 2005-12-15 19:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Fondo (m_fondo) Assigned to: Nobody/Anonymous (nobody) Summary: list.count() patch for feature request 1370948 Initial Comment: With patch, list.count() works like list.index() for start and end parameters ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 From noreply at sourceforge.net Fri Dec 16 04:15:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 19:15:16 -0800 Subject: [Patches] [ python-Patches-1382087 ] list.count() patch for feature request 1370948 Message-ID: Patches item #1382087, was opened at 2005-12-15 20:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Fondo (m_fondo) >Assigned to: Guido van Rossum (gvanrossum) Summary: list.count() patch for feature request 1370948 Initial Comment: With patch, list.count() works like list.index() for start and end parameters ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-15 22:15 Message: Logged In: YES user_id=80475 Other than consistency is there a reason for the patch? I understand that str.count and list.index both have optional start/stop arguments, but those both have use cases. AFAICT, no real-world use cases have been presented for list.count with start/stop arguments. A quick grep of the standard library does not reveal ANY code that would be improved as a result of this patch. The proposal does have some minor disadvantages: 1) complicating the signature and docs, 2) introducing a inter-version incompatability, 3) slowing the method call (changing from METH_O to METH_ARGS). Unless some offsetting benefits are shown, this patch should probably not be accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 From noreply at sourceforge.net Fri Dec 16 06:11:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Dec 2005 21:11:04 -0800 Subject: [Patches] [ python-Patches-1382163 ] Expose Subversion revision number Message-ID: Patches item #1382163, was opened at 2005-12-16 00:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Expose Subversion revision number Initial Comment: The attached patch calculates and exposes the Subversion build number, if available, to Python. If not building Python from a Subversion checkout, the old build number algorithm is used (although it is still newly exposed to Python via sys.build_number). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382163&group_id=5470 From noreply at sourceforge.net Fri Dec 16 16:04:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 07:04:20 -0800 Subject: [Patches] [ python-Patches-1382087 ] list.count() patch for feature request 1370948 Message-ID: Patches item #1382087, was opened at 2005-12-15 19:57 Message generated for change (Comment added) made by m_fondo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Mike Fondo (m_fondo) Assigned to: Guido van Rossum (gvanrossum) Summary: list.count() patch for feature request 1370948 Initial Comment: With patch, list.count() works like list.index() for start and end parameters ---------------------------------------------------------------------- >Comment By: Mike Fondo (m_fondo) Date: 2005-12-16 09:04 Message: Logged In: YES user_id=1406113 With those considerations in mind, I can't disagree. Rejecting would be best. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-15 21:15 Message: Logged In: YES user_id=80475 Other than consistency is there a reason for the patch? I understand that str.count and list.index both have optional start/stop arguments, but those both have use cases. AFAICT, no real-world use cases have been presented for list.count with start/stop arguments. A quick grep of the standard library does not reveal ANY code that would be improved as a result of this patch. The proposal does have some minor disadvantages: 1) complicating the signature and docs, 2) introducing a inter-version incompatability, 3) slowing the method call (changing from METH_O to METH_ARGS). Unless some offsetting benefits are shown, this patch should probably not be accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 From noreply at sourceforge.net Fri Dec 16 16:15:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 07:15:36 -0800 Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304) Message-ID: Patches item #677103, was opened at 2003-01-29 16:49 Message generated for change (Comment added) made by stevenknight You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: PYTHONBYTECODEBASE patch (PEP 304) Initial Comment: This is just a placeholder patch related to PEP 304. Feel free to comment on it. It's far from complete at this point. The first patch is just to see if we can do all the proper detection at startup. These checks have to be performed before any .py files are imported, otherwise you'd have some .pyc files dumped out before the machinery is ready to go. The first patch contains mods to sysmodule.c with next to no concern for platform independence. There is a small shell script and a few expected output files which are used to test setting of various values. These should probably be wrapped into regular PyUnit tests which popen() the interpreter with different settings, but this seemed quicker as a start. ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2005-12-16 09:15 Message: Logged In: YES user_id=216109 Skip-- Is there any interest in this patch getting accepted into core Python? Are there any other known barriers apart from the Windows issues? If this would likely be accepted once the Windows issues are worked out, I might be able to spend some time looking at the Windows side. --SK ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-16 20:26 Message: Logged In: YES user_id=44345 Update patch for current CVS (2.5a0)... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 17:12 Message: Logged In: YES user_id=44345 *sigh* - let's try again... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 16:48 Message: Logged In: YES user_id=44345 Patch updated for current CVS (~ 2.4b2). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 11:37 Message: Logged In: YES user_id=44345 Another patch. This one fixes the problems of the one I withdrew yesterday. There are still problems: * A half dozen regression tests fail for various reasons which I haven't completely investigated. * Nothing has been done for Windows. Someone will have to step up to the plate for this. I can't build on Windows. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:51 Message: Logged In: YES user_id=44345 While not technically broken, the patch I just posted is a bit bent. Withdrawing for a little fixup... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:33 Message: Logged In: YES user_id=44345 Here's an updated context diff. It seems to do the right thing on my Mac OS X system. It won't currently do anything on Windows ( need help there). No more test cases, but if PYTHONBYTECODEBASE points to a valid directory, the .pyc files seem to get put in all the right places. To get the behavior, you'll have to configure --with-bytecodebase. Feedback, please... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-29 16:52 Message: Logged In: YES user_id=44345 second upload try - what the hell is with SF? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 From noreply at sourceforge.net Fri Dec 16 17:15:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 08:15:59 -0800 Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304) Message-ID: Patches item #677103, was opened at 2003-01-29 16:49 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: PYTHONBYTECODEBASE patch (PEP 304) Initial Comment: This is just a placeholder patch related to PEP 304. Feel free to comment on it. It's far from complete at this point. The first patch is just to see if we can do all the proper detection at startup. These checks have to be performed before any .py files are imported, otherwise you'd have some .pyc files dumped out before the machinery is ready to go. The first patch contains mods to sysmodule.c with next to no concern for platform independence. There is a small shell script and a few expected output files which are used to test setting of various values. These should probably be wrapped into regular PyUnit tests which popen() the interpreter with different settings, but this seemed quicker as a start. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-12-16 10:15 Message: Logged In: YES user_id=44345 I sorta lost interest (it was never really anything I needed anyway) when the Windows problems were raised, especially after nobody suggested fixes. If you'd like to update the patch and perhaps champion it, be my guest. Skip ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2005-12-16 09:15 Message: Logged In: YES user_id=216109 Skip-- Is there any interest in this patch getting accepted into core Python? Are there any other known barriers apart from the Windows issues? If this would likely be accepted once the Windows issues are worked out, I might be able to spend some time looking at the Windows side. --SK ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-16 20:26 Message: Logged In: YES user_id=44345 Update patch for current CVS (2.5a0)... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 17:12 Message: Logged In: YES user_id=44345 *sigh* - let's try again... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 16:48 Message: Logged In: YES user_id=44345 Patch updated for current CVS (~ 2.4b2). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 11:37 Message: Logged In: YES user_id=44345 Another patch. This one fixes the problems of the one I withdrew yesterday. There are still problems: * A half dozen regression tests fail for various reasons which I haven't completely investigated. * Nothing has been done for Windows. Someone will have to step up to the plate for this. I can't build on Windows. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:51 Message: Logged In: YES user_id=44345 While not technically broken, the patch I just posted is a bit bent. Withdrawing for a little fixup... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 16:33 Message: Logged In: YES user_id=44345 Here's an updated context diff. It seems to do the right thing on my Mac OS X system. It won't currently do anything on Windows ( need help there). No more test cases, but if PYTHONBYTECODEBASE points to a valid directory, the .pyc files seem to get put in all the right places. To get the behavior, you'll have to configure --with-bytecodebase. Feedback, please... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-29 16:52 Message: Logged In: YES user_id=44345 second upload try - what the hell is with SF? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 From noreply at sourceforge.net Fri Dec 16 18:20:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 09:20:05 -0800 Subject: [Patches] [ python-Patches-1382087 ] list.count() patch for feature request 1370948 Message-ID: Patches item #1382087, was opened at 2005-12-15 20:57 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Mike Fondo (m_fondo) Assigned to: Guido van Rossum (gvanrossum) Summary: list.count() patch for feature request 1370948 Initial Comment: With patch, list.count() works like list.index() for start and end parameters ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-16 12:20 Message: Logged In: YES user_id=6380 Right. ---------------------------------------------------------------------- Comment By: Mike Fondo (m_fondo) Date: 2005-12-16 10:04 Message: Logged In: YES user_id=1406113 With those considerations in mind, I can't disagree. Rejecting would be best. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-15 22:15 Message: Logged In: YES user_id=80475 Other than consistency is there a reason for the patch? I understand that str.count and list.index both have optional start/stop arguments, but those both have use cases. AFAICT, no real-world use cases have been presented for list.count with start/stop arguments. A quick grep of the standard library does not reveal ANY code that would be improved as a result of this patch. The proposal does have some minor disadvantages: 1) complicating the signature and docs, 2) introducing a inter-version incompatability, 3) slowing the method call (changing from METH_O to METH_ARGS). Unless some offsetting benefits are shown, this patch should probably not be accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:22:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:22:08 -0800 Subject: [Patches] [ python-Patches-1376914 ] fix description of format_exc in traceback doc Message-ID: Patches item #1376914, was opened at 2005-12-09 07:16 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376914&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: fix description of format_exc in traceback doc Initial Comment: traceback.format_exc() docs erroneously mentioned file argument ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:22 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in revision 41710/41711. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1376914&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:24:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:24:16 -0800 Subject: [Patches] [ python-Patches-1377848 ] xml.parsers.expat documentation fix Message-ID: Patches item #1377848, was opened at 2005-12-10 21:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1377848&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: xml.parsers.expat documentation fix Initial Comment: The included patch fixes a typo for the overridable StartCdataSectionHandler func. Doc location: Doc/lib/libpyexpat.tex ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:24 Message: Logged In: YES user_id=1188172 Thanks for the report, fixed in rev. 41712/41713. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1377848&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:25:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:25:01 -0800 Subject: [Patches] [ python-Patches-1379332 ] StreamReader.readline with size reading multiple lines Message-ID: Patches item #1379332, was opened at 2005-12-13 09:54 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) >Assigned to: Walter D?rwald (doerwalter) Summary: StreamReader.readline with size reading multiple lines Initial Comment: In Python 2.4.2 and trunk, when StreamReader.readline is used with a size argument, it will eventually truncate some lines, even if every line is less than the size. It works correctly in Python 2.3.5, I haven't tried other versions. >>> f=codecs.getreader('ascii')(StringIO.StringIO("hello\nworld\n")) >>> f.readline(8) u'hello\n' >>> f.readline(8) u'wo' >>> f.readline(8) u'rld\n' I've attached a patch which fixes this and modifies test_codecs.py to test this. I don't know if this is the best way to fix it, but I didn't want to make deeper changes to the caching mechanism, being unfamiliar with this code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379332&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:29:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:29:54 -0800 Subject: [Patches] [ python-Patches-1382087 ] list.count() patch for feature request 1370948 Message-ID: Patches item #1382087, was opened at 2005-12-15 19:57 Message generated for change (Comment added) made by m_fondo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Mike Fondo (m_fondo) Assigned to: Guido van Rossum (gvanrossum) Summary: list.count() patch for feature request 1370948 Initial Comment: With patch, list.count() works like list.index() for start and end parameters ---------------------------------------------------------------------- >Comment By: Mike Fondo (m_fondo) Date: 2005-12-16 13:29 Message: Logged In: YES user_id=1406113 That was a pretty sappy response, eh? Oh well, I stand by it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-16 11:20 Message: Logged In: YES user_id=6380 Right. ---------------------------------------------------------------------- Comment By: Mike Fondo (m_fondo) Date: 2005-12-16 09:04 Message: Logged In: YES user_id=1406113 With those considerations in mind, I can't disagree. Rejecting would be best. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-12-15 21:15 Message: Logged In: YES user_id=80475 Other than consistency is there a reason for the patch? I understand that str.count and list.index both have optional start/stop arguments, but those both have use cases. AFAICT, no real-world use cases have been presented for list.count with start/stop arguments. A quick grep of the standard library does not reveal ANY code that would be improved as a result of this patch. The proposal does have some minor disadvantages: 1) complicating the signature and docs, 2) introducing a inter-version incompatability, 3) slowing the method call (changing from METH_O to METH_ARGS). Unless some offsetting benefits are shown, this patch should probably not be accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382087&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:37:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:37:34 -0800 Subject: [Patches] [ python-Patches-1360443 ] correct display of pathnames in SimpleHTTPServer Message-ID: Patches item #1360443, was opened at 2005-11-18 20:03 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360443&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: correct display of pathnames in SimpleHTTPServer Initial Comment: The patch makes the simple file server display path names that includes reserved and unsafe characters. Previously, a path named dir&a was displayed as dir%26a since "self.path" was processed by urllib.quote. The "path" parameter, however, is untouched. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:37 Message: Logged In: YES user_id=1188172 Thanks for the patch. There was an error in it, as the parameter "path" contains the local path and "self.path" the path relative to the server root. I committed a corrected version in rev. 41714/41715. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360443&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:40:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:40:23 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 15:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) >Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:40 Message: Logged In: YES user_id=1188172 Assigning to Guido for final word regarding PEP 341. I've not checked the patch for errors, I'm not firm enough with AST etc. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-17 07:03 Message: Logged In: YES user_id=315535 lol ... even if it doesn't get accepted, it was a great learning experience. The PEP itself hasn't even been approved as yet, I've just wanted this syntax in Python for a while :) Anyway ... might try my hand at a few ideas I have for that arena/pool stuff as discussed on python-dev when I get home tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-17 06:48 Message: Logged In: YES user_id=33168 Maybe I'm just tired, but I can't find any problems. Assuming this patch gets in, it ought to be the least buggy code in compile.c. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 14:52 Message: Logged In: YES user_id=315535 You're absolutely right with those bugs Nick. Fixed now. See how you go with v9 :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 14:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 10:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 09:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 06:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 14:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 05:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 05:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 05:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 13:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 09:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 06:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 06:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 01:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 00:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 00:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 00:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 22:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 16:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Fri Dec 16 20:42:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 11:42:29 -0800 Subject: [Patches] [ python-Patches-1212287 ] mode argument for fileinput class Message-ID: Patches item #1212287, was opened at 2005-05-31 23:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) >Assigned to: Raymond Hettinger (rhettinger) Summary: mode argument for fileinput class Initial Comment: This patch is in follow-up to bug #860515. It allows to specify a mode argument to the fileinput functions which can be r, rb, rU and U. Complete with test and doc. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 20:42 Message: Logged In: YES user_id=1188172 Any other comments? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 17:36 Message: Logged In: YES user_id=261020 I reviewed this patch and ran the test. Looks good to me. The docs need a \versionchanged for each of the two changed callables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212287&group_id=5470 From noreply at sourceforge.net Fri Dec 16 22:43:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 13:43:16 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 09:59 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) >Assigned to: Neal Norwitz (nnorwitz) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-16 16:43 Message: Logged In: YES user_id=6380 PEP 341 is accepted (sorry, I thought I had accepted it in May!). Assigning to Neal for final verification and checkin. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 14:40 Message: Logged In: YES user_id=1188172 Assigning to Guido for final word regarding PEP 341. I've not checked the patch for errors, I'm not firm enough with AST etc. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-17 01:03 Message: Logged In: YES user_id=315535 lol ... even if it doesn't get accepted, it was a great learning experience. The PEP itself hasn't even been approved as yet, I've just wanted this syntax in Python for a while :) Anyway ... might try my hand at a few ideas I have for that arena/pool stuff as discussed on python-dev when I get home tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-17 00:48 Message: Logged In: YES user_id=33168 Maybe I'm just tired, but I can't find any problems. Assuming this patch gets in, it ought to be the least buggy code in compile.c. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 08:52 Message: Logged In: YES user_id=315535 You're absolutely right with those bugs Nick. Fixed now. See how you go with v9 :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 08:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 04:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 03:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 00:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 08:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 23:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 23:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 23:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 07:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 03:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 00:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 00:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 19:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 18:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 18:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 18:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 16:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 10:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Sat Dec 17 05:02:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Dec 2005 20:02:34 -0800 Subject: [Patches] [ python-Patches-1383115 ] Specify new reference return value for PyObject_Call Message-ID: Patches item #1383115, was opened at 2005-12-17 04:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1383115&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Farshid Lashkari (farshizzo) Assigned to: Nobody/Anonymous (nobody) Summary: Specify new reference return value for PyObject_Call Initial Comment: Hi, >From my understanding, the C API function PyObject_Call returns a new reference, but the documentation does not specify this. I've attached a modified version of the appropriate doc page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1383115&group_id=5470 From noreply at sourceforge.net Sat Dec 17 11:19:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 02:19:07 -0800 Subject: [Patches] [ python-Patches-1166195 ] Using size_t where appropriate Message-ID: Patches item #1166195, was opened at 2005-03-18 20:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166195&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Using size_t where appropriate Initial Comment: This patch is (a first draft of) an attempt to make Python properly use size_t where necessary. This work is triggered by compilation on Win64 (where the compiler warns about potential truncation errors a lot). The rationale for the patch is that size_t might be larger than int, in particular on 64-bit platforms, and that the size of a memory chunk cannot reliably be measured with an int. It turns out that using size_t is not enough, since values can sometimes also be negative. For these cases, a "signed" size_t is used, which is called Py_ssize_t and is a define for ssize_t if the compiler supports the latter. The guideline for converting int to size_t used in this patch is this: - if the variable is meant to store the number of bytes, and is always guaranteed to be positive, and could get arbitrarily large, use size_t - if the value could be negative also, use ssize_t - if the value is meant to store a number of "things", but this directly translates into size_t (e.g. number of pointers, number of characters), also use size_t/ssize_t - if the value is in a range limited to 32-bit int (e.g. the number of characters in a path name), convert the size_t to int, after asserting that the value really is in the range. This version is work in progress, and needs review. I hope to work on it during the sprints at PyConDC. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-12-17 11:19 Message: Logged In: YES user_id=21627 This patch is now maintained in http://svn.python.org/projects/python/branches/ssize_t/ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-06 09:06 Message: Logged In: YES user_id=21627 Second version of the patch attached (PyCon version). It turns out that changing everything from signed to unsigned breaks too many things, so this version of the patch uses Py_ssize_t in nearly all places. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1166195&group_id=5470 From noreply at sourceforge.net Sat Dec 17 18:04:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 09:04:40 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Sat Dec 17 22:34:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 13:34:22 -0800 Subject: [Patches] [ python-Patches-1355913 ] PEP 341 - Unification of try/except and try/finally Message-ID: Patches item #1355913, was opened at 2005-11-13 06:59 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Neal Norwitz (nnorwitz) Summary: PEP 341 - Unification of try/except and try/finally Initial Comment: Attached is a patch implementing PEP 341 against HEAD in subversion. It includes the following changes: 1. Grammar/Grammar updated as per the PEP 2. Python/ast.c wraps try/except blocks inside try/finally blocks if it detects the extended syntax. This patch is based heavily upon suggestions by Nick Coghlan on python-dev. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 13:34 Message: Logged In: YES user_id=33168 Thanks Thomas! Committed revision 41740. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-16 13:43 Message: Logged In: YES user_id=6380 PEP 341 is accepted (sorry, I thought I had accepted it in May!). Assigning to Neal for final verification and checkin. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-16 11:40 Message: Logged In: YES user_id=1188172 Assigning to Guido for final word regarding PEP 341. I've not checked the patch for errors, I'm not firm enough with AST etc. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 22:03 Message: Logged In: YES user_id=315535 lol ... even if it doesn't get accepted, it was a great learning experience. The PEP itself hasn't even been approved as yet, I've just wanted this syntax in Python for a while :) Anyway ... might try my hand at a few ideas I have for that arena/pool stuff as discussed on python-dev when I get home tonight. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-16 21:48 Message: Logged In: YES user_id=33168 Maybe I'm just tired, but I can't find any problems. Assuming this patch gets in, it ought to be the least buggy code in compile.c. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 05:52 Message: Logged In: YES user_id=315535 You're absolutely right with those bugs Nick. Fixed now. See how you go with v9 :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-16 05:25 Message: Logged In: YES user_id=1038590 Closest yet, but I don't think we're quite there yet. The 'except_st = NULL' part should be on the line immediately after except_st is inserted into the inner sequence. As soon as that insertion happens, we want to ensure that the statement is only freed once. What's currently there will technically work, but doesn't really have the right semantics. More importantly, the "body = handlers = orelse = NULL" part should only be executed if the call to TryExcept *succeeds*, not if it fails. Neil's right - we seriously need to find a better way to handle this memory management or it will be a source of significant pain (well, more pain than you've already experienced ;) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 01:23 Message: Logged In: YES user_id=315535 Okay, here we go: v8! *sighs* this is devestating for my ego :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-16 00:35 Message: Logged In: YES user_id=315535 Arrgh! :) Well ... I'll fix up this patch & submit it again. I might fall back to the 'goto' style of doing things just so we don't have the mix of "do ... break ... while" and goto (which I imagine could be almost as confusing as the mix of check-cleanup and goto-cleanup as described by Nick earlier). Again, if you could check the v8 patch for me it would be much appreciated. After that, I might hit python-dev and read up on what everybody's been saying about pools/arenas & maybe get started on something we can use for the AST ... anyway, I'll discuss that on python-dev. This isn't really the place for it :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 21:38 Message: Logged In: YES user_id=33168 ISTM there are a couple of problems. Some of these were likely in there before and I may have told you to do some. :-( I probably made the same error too. :-( :-( One is a new one though. That starts in the for loop. You break in there, but that only breaks out of the for loop, doesn't it? So you really need a goto to break out I think. After setting except_st, it holds references to body, handlers, and orelse, so if you free except_st, it should free all the others. Therefore if except_st was created (after the if (except_st) break;), you should set body = handlers = orelse = NULL; Do you agree? I think if you don't you will get a double free. The same would go for after you asdl_seq_SET(inner, 0, except_st); you should set except_st = NULL; OTOH, you fixed a memory leak. Whenever one does return TryExcept(); (or any other similar AST call), if TryExcept fails, we will return NULL and all the local variables will be leaked. *sigh* Sorry you have to deal with this crap. You've been a very good guinea pig being the first. I really hope we do the arenas as discussed on python-dev. If you aren't too burnt out, it would be a really good way to learn the rest of the AST. :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 05:15 Message: Logged In: YES user_id=315535 Here's the v7 patch against revision 41451, with Neal's last fix :) Using Marek's suggestion for try/except emulation in C from python-dev to avoid the "goto" crap. Any more problems here? *looks hopeful* :) - Tom ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:50 Message: Logged In: YES user_id=315535 lol thanks Neal/Nick, that's fine. :) Nick Coghlan and yourself have been extremely helpful throughout this whole process, and it's been a great learning experience. I'll implement your suggested fix for 'handlers' right away. If you like, let me know when you've committed the 700+ line patch and I'll generate the PEP 341 patch from that. - Tom ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 20:43 Message: Logged In: YES user_id=33168 Oh, so close, I'm sorry, I see one more problem. :-) Thomas, I hope you will write up this experience in coding this patch. IMO it clearly demonstrates a problem with the new AST code that needs to be addressed. ie, Memory management is not possible to get right. I've got a 700+ line patch to ast.c to correct many more memory issues (hopefully that won't cause conflicts with this patch). I would like to hear ideas of how the AST code can be improved to make it much easier to not leak memory and be safe at the same time. The problem is that handlers is not an asdl_seq of stmt's, but rather an asdl_seq of exceptionhandlers. There is no utility function to clean out this seq, so you need to do it manually. for (i = 0; i < asdl_seq_LEN(handlers); i++) free_exceptionhandler(asdl_seq_GET(handlers, i)); asdl_seq_free(handlers); I don't see any other problems, but perhaps I will when it gets checked in or I run valgrind on it. The Other Nick :-) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 20:10 Message: Logged In: YES user_id=315535 Okay, v6 is up. Now using test-goto-cleanup. Also using asdl_stmt_seq_free. Any more suggestions/feedback? Anybody having trouble using this patch? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 04:14 Message: Logged In: YES user_id=315535 Thanks for your input Nick - I'll sort out a patch taking your suggestions into consideration tomorrow & resubmit it. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-14 00:54 Message: Logged In: YES user_id=1038590 >From a code inspection of v5 of the patch (I haven't actually run the patch anywhere), I'm a little uncomfortable with the mixture of the two error handling styles (that is, test-cleanup-return for most of the function, but test-goto-cleanup for the one specific case). I don't mind either style (and both are used in the Python source), but mixing them in one function bothers me :) Further, there appears to be a bug in the deallocation code, in that all sequences should be freed with adsl_seq_stmt_free. The current direct use of adsl_seq_free means any contained statements are not released. I suggest putting a single 'error' label at the end of the function that uses adsl_seq_stmt_free to clean up all the statement sequences , as well as free_stmt to clean up the nested except statements. As both of these functions handle nulls gracefully, the bodies of the current error cleanup and return branches can all then be replaced with "goto error". ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:18 Message: Logged In: YES user_id=315535 Oops - I mean Neal :) ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 21:17 Message: Logged In: YES user_id=315535 Fix for the problem you encountered in the v5 patch, Nick. All tests in the suite now pass for me, no assertion failures when using --with-pydebug. I was stupidly generating a TryFinally in every scenario. This breaks down in the 'trace' unit test when no 'finally' clause is present with the extended syntax. Oops. Also added a little more error checking code and updated the unit test to test nested exception handling. I'm using a few goto statements in the "if (n_except > 0)" branch to reduce duplication deallocating memory. If there's any great objections to this feel free to yell & I'll resubmit a patch without the use of goto. Can you please verify this works for you, Nick? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 16:02 Message: Logged In: YES user_id=315535 Fixed a bad assumption when parsing a try-finally. Should be fixed now. I'm not sure if this fixes the problem you're experiencing, Neal. I'll have a look into it. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 15:12 Message: Logged In: YES user_id=315535 Further correction of memory leaks. 'finally' and 'orelse' need to be deallocated if an error occurs in the "if (n_except > 0)" branch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 15:10 Message: Logged In: YES user_id=33168 I'm pretty sure this patch causes this problem: python: Objects/frameobject.c:187: frame_setlineno: Assertion `blockstack_top > 0' failed. I'm not sure if it's just my hacked up version or the original. Thomas, can you test your version? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 13:27 Message: Logged In: YES user_id=33168 Updated patch to correct memory leaks. Put everything in one file. Works for me. There needs to be doc changes done too. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 07:02 Message: Logged In: YES user_id=315535 Attaching a unit test checking the various different types of exception handling syntax. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355913&group_id=5470 From noreply at sourceforge.net Sat Dec 17 22:39:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 13:39:53 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by michaelurman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-17 15:39 Message: Logged In: YES user_id=1404983 I've got a patch for the ParseTuple cases, but I don't seem to be able to attach it. For now it is available from http://www.tortall.net/mu/static/fmtcheck_parsetuple_41738_diff?raw It consists mostly of replacing signed formats with unsigned formats, and adding parse_foo temporary variables for parsing to a known size. There's also a couple cases where I just change the variable type to match the format when I'm fairly certain it's safe. I added the test on this ticket to test_mmap.py but added no other tests. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 01:40 Message: Logged In: YES user_id=1404983 Objects/ is clean on the ParseTuple, and all I see on BuildValue are due to limitations in my script. The script itself is available at http://www.tortall.net/mu/static/fmtcheck.py (linked via the blog entry as well if it moves later), and if GPL terms are useless, I'm willing to consider others. Regardless the script is currently too false-positive happy for automated use (i hope not false-negative happy). I am indeed Michael Urman. I don't know how quickly I'll have a final patch---perhaps by the end of the week---a lot of it is mind-numbing detail work. Feel free to preemptively obsolete parts of the patch as you see fit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 01:04 Message: Logged In: YES user_id=33168 Thanks for your comments. It made a lot more sense after I finished reading your blog. I think the signed-ness issues which relate to ("i", unsigned int) or ("l", unsigned long) should be fixed. I agree with your concern about fixing and backporting, though I don't know how best to address it. I'm not concerned about unsigned vs signed char * for 's' and 't' formats. I don't think they are a big deal which we seem to agree on. I fixed the bltinmodule.c:1910 problem. That wasn't really an issue since the variable was larger and not actually used. The problem with xxmodule.c:207 is in error checking code, so I'm not concerned about that. (It's checking that O# is invalid.) Can you run your script on Objects too? It would be great if we got your script into the python tree too so we can search for these things in the future. (Ideally we would have complete unittests, but I'm not holding my breath for that to happen.) For the record is your name Michael Urman? I would like to add you to the ACKS file. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 00:43 Message: Logged In: YES user_id=1404983 Neal, thanks for the additional encouragement. The issues I'm worried about with regard to signed/unsigned are on the user code side. In most cases it's a signed format string matching to an unsigned variable, and often is for a positive only value (count or length, or similar). I doubt more than a couple python programs try to use values large enough for it to be relevant (outside of semantically questionable -1 markers), however before arbitrarily changing format strings, I want to be sure such a -1 value parsed with an unsigned format string will not start raising ValueErrors - I want my patch to be a candidate for backporting if desired. Better to leave well enough alone if it's mostly safe. There are also tons of unsigned char * variables passed for string formats; since I don't know why they are explicitly unsigned, and most of Python works as is, I'd rather just leave those alone. It would suck to hit one of the special cases for which it really needs to be an unsigned char *. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 00:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 23:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 23:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 11:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Sun Dec 18 02:27:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 17:27:50 -0800 Subject: [Patches] [ python-Patches-1382163 ] Expose Subversion revision number Message-ID: Patches item #1382163, was opened at 2005-12-16 00:11 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Expose Subversion revision number Initial Comment: The attached patch calculates and exposes the Subversion build number, if available, to Python. If not building Python from a Subversion checkout, the old build number algorithm is used (although it is still newly exposed to Python via sys.build_number). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-12-17 20:27 Message: Logged In: YES user_id=12800 Accepted and committed with some changes as discussed on python-dev. r41744 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1382163&group_id=5470 From noreply at sourceforge.net Sun Dec 18 04:34:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 19:34:42 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 14:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.4 >Status: Closed Resolution: None >Priority: 5 Submitted By: Joe Wreschnig (piman) >Assigned to: Neal Norwitz (nnorwitz) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 19:34 Message: Logged In: YES user_id=33168 Michael, I checked in a variation of your patch. The reason you can't attach a file to this report is because SF is annoying. You can only attach files to reports you own. So it would be great if you can open a new report and attach your patch against svn HEAD. Thanks. Committed revision 41748. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-17 13:39 Message: Logged In: YES user_id=1404983 I've got a patch for the ParseTuple cases, but I don't seem to be able to attach it. For now it is available from http://www.tortall.net/mu/static/fmtcheck_parsetuple_41738_diff?raw It consists mostly of replacing signed formats with unsigned formats, and adding parse_foo temporary variables for parsing to a known size. There's also a couple cases where I just change the variable type to match the format when I'm fairly certain it's safe. I added the test on this ticket to test_mmap.py but added no other tests. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 23:40 Message: Logged In: YES user_id=1404983 Objects/ is clean on the ParseTuple, and all I see on BuildValue are due to limitations in my script. The script itself is available at http://www.tortall.net/mu/static/fmtcheck.py (linked via the blog entry as well if it moves later), and if GPL terms are useless, I'm willing to consider others. Regardless the script is currently too false-positive happy for automated use (i hope not false-negative happy). I am indeed Michael Urman. I don't know how quickly I'll have a final patch---perhaps by the end of the week---a lot of it is mind-numbing detail work. Feel free to preemptively obsolete parts of the patch as you see fit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 23:04 Message: Logged In: YES user_id=33168 Thanks for your comments. It made a lot more sense after I finished reading your blog. I think the signed-ness issues which relate to ("i", unsigned int) or ("l", unsigned long) should be fixed. I agree with your concern about fixing and backporting, though I don't know how best to address it. I'm not concerned about unsigned vs signed char * for 's' and 't' formats. I don't think they are a big deal which we seem to agree on. I fixed the bltinmodule.c:1910 problem. That wasn't really an issue since the variable was larger and not actually used. The problem with xxmodule.c:207 is in error checking code, so I'm not concerned about that. (It's checking that O# is invalid.) Can you run your script on Objects too? It would be great if we got your script into the python tree too so we can search for these things in the future. (Ideally we would have complete unittests, but I'm not holding my breath for that to happen.) For the record is your name Michael Urman? I would like to add you to the ACKS file. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 22:43 Message: Logged In: YES user_id=1404983 Neal, thanks for the additional encouragement. The issues I'm worried about with regard to signed/unsigned are on the user code side. In most cases it's a signed format string matching to an unsigned variable, and often is for a positive only value (count or length, or similar). I doubt more than a couple python programs try to use values large enough for it to be relevant (outside of semantically questionable -1 markers), however before arbitrarily changing format strings, I want to be sure such a -1 value parsed with an unsigned format string will not start raising ValueErrors - I want my patch to be a candidate for backporting if desired. Better to leave well enough alone if it's mostly safe. There are also tons of unsigned char * variables passed for string formats; since I don't know why they are explicitly unsigned, and most of Python works as is, I'd rather just leave those alone. It would suck to hit one of the special cases for which it really needs to be an unsigned char *. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 22:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 21:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 21:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 12:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 09:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 09:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 03:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 13:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 11:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Sun Dec 18 04:37:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Dec 2005 19:37:22 -0800 Subject: [Patches] [ python-Patches-1291169 ] mmap with unsigned int offset and cross build for ppc Message-ID: Patches item #1291169, was opened at 2005-09-14 10:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1291169&group_id=5470 Please note that this 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.5 Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Jos? Pedro Pereira Valente de M (jose-v-matos) Assigned to: Nobody/Anonymous (nobody) Summary: mmap with unsigned int offset and cross build for ppc Initial Comment: # Based on "K's cluttered loft - ARM cross-compiling howto" http://www.ailis.de/~k/docs/crosscompiling/python.php and mmap patch from Yotam Medini yotamm at mellanox.co.il. I've created a script in attach that does the cross_compile. Also in the script is the diff from "cvs diff -u " I changed the mmapmodule.c to use unsigned int, and therefor not report OverflowError. I would like to use python to do automatic tests on chips in boards that are usually mapped on high address values like 0xFFF00000. Right now I can do that. Needs patch to the tests and documentation, I think. Hope this helps someone. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 19:37 Message: Logged In: YES user_id=33168 Some mmap changes have been fixed to handle 64 bit issues. Note this patch is really several different patches rolled into one (mmap enhancements and testing changes, setup.py changes, plus Makefile changes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1291169&group_id=5470 From noreply at sourceforge.net Sun Dec 18 16:22:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 07:22:45 -0800 Subject: [Patches] [ python-Patches-1365916 ] [PATCH] mmap fails on AMD64 Message-ID: Patches item #1365916, was opened at 2005-11-24 16:22 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Joe Wreschnig (piman) Assigned to: Neal Norwitz (nnorwitz) Summary: [PATCH] mmap fails on AMD64 Initial Comment: mmap_move_method is not 64-bit safe, and fails on the following code: from mmap import mmap f = open('test.out', 'ab+') f.write('ABCDEabcde') f.flush() m = mmap(f.fileno(), 10) m.move(5, 0, 5) m.read(10) To fix this, mmapmodule.c:538 needs to use "LLL:move" instead of "iii:move" (this also fixes #1921169, which changed it from "iii" to "III"). This is in both Python 2.3 and 2.4. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-12-18 09:22 Message: Logged In: YES user_id=2772 Just did an svn update and built on my FC4/x86_64 system. The test code seems to now give the expected result instead of an exception. >>> m.read(10) 'ABCDEABCDE' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 21:34 Message: Logged In: YES user_id=33168 Michael, I checked in a variation of your patch. The reason you can't attach a file to this report is because SF is annoying. You can only attach files to reports you own. So it would be great if you can open a new report and attach your patch against svn HEAD. Thanks. Committed revision 41748. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-17 15:39 Message: Logged In: YES user_id=1404983 I've got a patch for the ParseTuple cases, but I don't seem to be able to attach it. For now it is available from http://www.tortall.net/mu/static/fmtcheck_parsetuple_41738_diff?raw It consists mostly of replacing signed formats with unsigned formats, and adding parse_foo temporary variables for parsing to a known size. There's also a couple cases where I just change the variable type to match the format when I'm fairly certain it's safe. I added the test on this ticket to test_mmap.py but added no other tests. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 01:40 Message: Logged In: YES user_id=1404983 Objects/ is clean on the ParseTuple, and all I see on BuildValue are due to limitations in my script. The script itself is available at http://www.tortall.net/mu/static/fmtcheck.py (linked via the blog entry as well if it moves later), and if GPL terms are useless, I'm willing to consider others. Regardless the script is currently too false-positive happy for automated use (i hope not false-negative happy). I am indeed Michael Urman. I don't know how quickly I'll have a final patch---perhaps by the end of the week---a lot of it is mind-numbing detail work. Feel free to preemptively obsolete parts of the patch as you see fit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 01:04 Message: Logged In: YES user_id=33168 Thanks for your comments. It made a lot more sense after I finished reading your blog. I think the signed-ness issues which relate to ("i", unsigned int) or ("l", unsigned long) should be fixed. I agree with your concern about fixing and backporting, though I don't know how best to address it. I'm not concerned about unsigned vs signed char * for 's' and 't' formats. I don't think they are a big deal which we seem to agree on. I fixed the bltinmodule.c:1910 problem. That wasn't really an issue since the variable was larger and not actually used. The problem with xxmodule.c:207 is in error checking code, so I'm not concerned about that. (It's checking that O# is invalid.) Can you run your script on Objects too? It would be great if we got your script into the python tree too so we can search for these things in the future. (Ideally we would have complete unittests, but I'm not holding my breath for that to happen.) For the record is your name Michael Urman? I would like to add you to the ACKS file. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-15 00:43 Message: Logged In: YES user_id=1404983 Neal, thanks for the additional encouragement. The issues I'm worried about with regard to signed/unsigned are on the user code side. In most cases it's a signed format string matching to an unsigned variable, and often is for a positive only value (count or length, or similar). I doubt more than a couple python programs try to use values large enough for it to be relevant (outside of semantically questionable -1 markers), however before arbitrarily changing format strings, I want to be sure such a -1 value parsed with an unsigned format string will not start raising ValueErrors - I want my patch to be a candidate for backporting if desired. Better to leave well enough alone if it's mostly safe. There are also tons of unsigned char * variables passed for string formats; since I don't know why they are explicitly unsigned, and most of Python works as is, I'd rather just leave those alone. It would suck to hit one of the special cases for which it really needs to be an unsigned char *. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-15 00:16 Message: Logged In: YES user_id=33168 I read your blog and I entirely agree that we need more unit tests. The more you can provide the better. I have an AMD64 so can test it works before checkin. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-14 23:46 Message: Logged In: YES user_id=33168 Michael, I'm not sure I understand the issues in detail, however I will try to respond. signed/unsigned issues are probably used and checked inconsitently--be wary of them. There are potential issues when the high bit is set and whether that means a long or unsigned value. The meaning has changed in some versions of python. I would definitely like to see shadowed variables fixed. If you don't believe a comment is correct, you should fix the problem whatever it is. So fix the comment and/or code as you see fit. If the patch gets too large, feel free to break it up into several related components if that makes sense. I'm just starting to read over your analysis. Thanks for looking into these issues. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 23:38 Message: Logged In: YES user_id=1404983 Issues I've run into, and would like pre-patch feedback: Regarding signed/unsigned in general - is it python-code safe to change a signed format to an unsigned? Reading getargs.c it looks like bounds are only checked for the signed formats. This could be either good or bad. fcntlmodule.c: the reported char* type of arg on line 174 is due to a shadow variable (already scoped-out) earlier in the function. Is this worth changing? xxmodule.c: the use of # with a long is preceded by a comment about testing bad format characters. I'm unconvinced whether this is what it meant. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:06 Message: Logged In: YES user_id=4771 No, I'd also be interested in hearing about a decent reusable parser for C. The only one I know about is gccxml, and it seems to be an incredible mess to compile and to be broken on every other gcc version. ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 13:11 Message: Logged In: YES user_id=1404983 Alright, I'll work on creating a patch against HEAD. I'll see what I can do about writing tests for this, but in general I expect the only place to test it will be at the higher level with samples like the one in this report; it's certainly not worth writing ways to invasively check if a ParseTuple the right values in most scenarios. The BuildValue support from my script is very rough, but I'll see what I can do. If you know of any easy to use C parsers in Python, I wouldn't mind modifying the checker to get better results with it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-14 11:40 Message: Logged In: YES user_id=4771 Nice results, great work. My humble opinion on this is that all known instances should be fixed. The type size_t could be an int or a long depending on compiler/platform (or maybe even something else), so it should just not be used. Any signed/unsigned conflict should also be investigated; most but not all seem harmless. Of course, tests would be nice, but I don't completely see the point of spending too much efforts testing dark corners that we are pretty confident are getting fixed, when the code is under-tested to start with. The Py_BuildValue() logs are more tedious to look through. There are definitely some int-vs-long conflicts. There are signed/unsigned conflicts, but some are intended, e.g. in binascii -- in these cases, though, an explicit cast would not hurt. In any case if you embark on this clean-up, I volunteer to review and apply it (be sure to work on the subversion head). ---------------------------------------------------------------------- Comment By: Michael Urman (michaelurman) Date: 2005-12-14 11:11 Message: Logged In: YES user_id=1404983 Hi Armin, Joe finally convinced me to get the SF account myself. I've done some further analysis on this already at http://www.tortall.net/mu/blog/2005/12/01 and would be willing to create relevant patches for whatever change coverage level you would like to see. I.e. just for mmapmodule, just for glaring errors, or for creating temporary local variables to ensure all format string passing is okay in all ParseTuple instances known to be bad. Please let me know what patch or patches you would like me to create. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-13 05:09 Message: Logged In: YES user_id=4771 Could you do a complete review of the i/I/l/L issue in mmapmodule.c? There seems to be a fair amount of inconsistencies between them and the declared types of the variables -- for example, I don't think that assigning to size_t variables is a good idea; PyArg_ParseTuple() should only assign to int/unsigned int/long/unsigned long variables. ---------------------------------------------------------------------- Comment By: Joe Wreschnig (piman) Date: 2005-11-28 15:36 Message: Logged In: YES user_id=796 This is causing data corruption. There is also a trivial patch. There is no good reason not to fix it immediately. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2005-11-27 13:25 Message: Logged In: YES user_id=2772 I haven't tested the patch, but the above testcase does fail on my linux x86_64 machine with "ValueError: source or destination out of range" on the call to m.move(), but succeed on my linux x86 machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1365916&group_id=5470 From noreply at sourceforge.net Sun Dec 18 20:41:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 11:41:02 -0800 Subject: [Patches] [ python-Patches-1383115 ] Specify new reference return value for PyObject_Call Message-ID: Patches item #1383115, was opened at 2005-12-17 05:02 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1383115&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Farshid Lashkari (farshizzo) >Assigned to: Fredrik Lundh (effbot) Summary: Specify new reference return value for PyObject_Call Initial Comment: Hi, >From my understanding, the C API function PyObject_Call returns a new reference, but the documentation does not specify this. I've attached a modified version of the appropriate doc page. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-18 20:41 Message: Logged In: YES user_id=38376 PyObject_Call has the same behaviour as the other PyObject_CallXXX functions. I've updated the ref- count documentation. Thanks /F ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1383115&group_id=5470 From noreply at sourceforge.net Sun Dec 18 23:30:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Dec 2005 14:30:17 -0800 Subject: [Patches] [ python-Patches-1205436 ] Bugfix for signal-handler on x64 Platform Message-ID: Patches item #1205436, was opened at 2005-05-19 22:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Andr? Fritzsche (computercrustie) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix for signal-handler on x64 Platform Initial Comment: On x64 Platform (i used Visual Studio 2005 and Windows XP x64) the python.exe hang up on registering signal handler for none used signals. I fixed this on my machine with a switch-case construct for filtering the unsupported signals. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 14:30 Message: Logged In: YES user_id=33168 I believe this was fixed recently. Can you verify it works for you now? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-20 04:09 Message: Logged In: YES user_id=6656 Point the first: please attach patches, not files. Point the second: we think this is a microsoft bug. Quoting C99 (about the signal function): If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno. That doesn't seem to allow calling abort(). As I think VS 2005 is still in beta, there's still hope that this will get fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1205436&group_id=5470 From noreply at sourceforge.net Mon Dec 19 12:14:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 03:14:01 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Richard Barran (rbarran) Date: 2005-12-19 12:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Mon Dec 19 19:00:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 10:00:36 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 11:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 10:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 03:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 09:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 04:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-27 23:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Tue Dec 20 02:23:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 17:23:59 -0800 Subject: [Patches] [ python-Patches-1335054 ] Python 2.4.2 doesn't build with "--without-threads" Message-ID: Patches item #1335054, was opened at 2005-10-22 21:51 Message generated for change (Comment added) made by phodifoo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 Please note that this 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.4 Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Gunter Ohrner (interneci) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.4.2 doesn't build with "--without-threads" Initial Comment: Build fix is attached. (Not yet runtime tested.) ---------------------------------------------------------------------- Comment By: phodifoo (phodifoo) Date: 2005-12-20 02:23 Message: Logged In: YES user_id=1230133 > This was fixed a while ago. Thanks. but it still doesn't compile in 2.4.2 the fix has somehow been lost !!! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-02 08:11 Message: Logged In: YES user_id=33168 This was fixed a while ago. Thanks. ---------------------------------------------------------------------- Comment By: Francois Perrad (fperrad) Date: 2005-10-28 09:22 Message: Logged In: YES user_id=1293818 Just an alternate patch : --- pystate.c.orig 2005-10-27 17:35:32.000000000 +0200 +++ pystate.c 2005-10-27 17:47:16.000000000 +0200 @@ -42,10 +42,14 @@ */ static PyInterpreterState *autoInterpreterState = NULL; static int autoTLSkey = 0; + +static void _PyGILState_NoteThreadState(PyThreadState* tstate); #else #define HEAD_INIT() /* Nothing */ #define HEAD_LOCK() /* Nothing */ #define HEAD_UNLOCK() /* Nothing */ + +#define _PyGILState_NoteThreadState(tstate) #endif static PyInterpreterState *interp_head = NULL; @@ -53,8 +57,6 @@ PyThreadState *_PyThreadState_Current = NULL; PyThreadFrameGetter _PyThreadState_GetFrame = NULL; -static void _PyGILState_NoteThreadState(PyThreadState* tstate); - PyInterpreterState * PyInterpreterState_New(void) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 From noreply at sourceforge.net Tue Dec 20 02:34:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Dec 2005 17:34:16 -0800 Subject: [Patches] [ python-Patches-1335054 ] Python 2.4.2 doesn't build with "--without-threads" Message-ID: Patches item #1335054, was opened at 2005-10-22 12:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 Please note that this 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.4 Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Gunter Ohrner (interneci) Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.4.2 doesn't build with "--without-threads" Initial Comment: Build fix is attached. (Not yet runtime tested.) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 17:34 Message: Logged In: YES user_id=33168 It was fixed in CVS/SVN. You will need to pull down the changes from source. When 2.4.3 is released it should incorporate these changes. ---------------------------------------------------------------------- Comment By: phodifoo (phodifoo) Date: 2005-12-19 17:23 Message: Logged In: YES user_id=1230133 > This was fixed a while ago. Thanks. but it still doesn't compile in 2.4.2 the fix has somehow been lost !!! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-01 23:11 Message: Logged In: YES user_id=33168 This was fixed a while ago. Thanks. ---------------------------------------------------------------------- Comment By: Francois Perrad (fperrad) Date: 2005-10-28 00:22 Message: Logged In: YES user_id=1293818 Just an alternate patch : --- pystate.c.orig 2005-10-27 17:35:32.000000000 +0200 +++ pystate.c 2005-10-27 17:47:16.000000000 +0200 @@ -42,10 +42,14 @@ */ static PyInterpreterState *autoInterpreterState = NULL; static int autoTLSkey = 0; + +static void _PyGILState_NoteThreadState(PyThreadState* tstate); #else #define HEAD_INIT() /* Nothing */ #define HEAD_LOCK() /* Nothing */ #define HEAD_UNLOCK() /* Nothing */ + +#define _PyGILState_NoteThreadState(tstate) #endif static PyInterpreterState *interp_head = NULL; @@ -53,8 +57,6 @@ PyThreadState *_PyThreadState_Current = NULL; PyThreadFrameGetter _PyThreadState_GetFrame = NULL; -static void _PyGILState_NoteThreadState(PyThreadState* tstate); - PyInterpreterState * PyInterpreterState_New(void) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335054&group_id=5470 From noreply at sourceforge.net Wed Dec 21 05:20:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Dec 2005 20:20:13 -0800 Subject: [Patches] [ python-Patches-1335972 ] Fix for int(string, base) wrong answers (take 2) Message-ID: Patches item #1335972, was opened at 2005-10-24 00:33 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for int(string, base) wrong answers (take 2) Initial Comment: This incorporates patch #1334979, adds test cases for all the cases listed in bug #1334662, and adds test cases for evaluation of 2**32+1. There seem to be some minor speed improvements (simplistic stats shown below). Some simple performance test scripts have been included in the attached file as well. A lookup table was added for the maximum number of digits that can never overflow on a 32-bit ulong for each base. Overflow is only checked when this limit is exceeded by 1, and once the input string is determined to be too long (2 over the limit), the evaluation is halted and an overflow indication is returned. This appears to help reduce the evaluation time for very long strings (no time is wasted trying to evaluate all of it into a 32-bit ulong). Evaluation of each character has also been replaced by a lookup table. I'm not certain of the amount of speed benefit obtained from this; I added it early on and haven't had time to go back and test. It may be that it's not worth the extra static table. Baseline Python from CVS: alan at tarantula:~/python/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 5.49 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 11.8 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 13.4 usec per loop alan at tarantula:~/python/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 997 usec per loop Modified: alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("9")' 100000 loops, best of 3: 3.63 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999")' 100000 loops, best of 3: 3.93 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999")' 100000 loops, best of 3: 9.79 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("999999999999999")' 100000 loops, best of 3: 11 usec per loop alan at tarantula:~/python_testint/dist/src# ./python -m timeit 'int("1"*600)' 1000 loops, best of 3: 905 usec per loop 10.2% faster for 1-digit int 39.7% faster for 9-digit int 20.5% faster for 12-digit int 21.8% faster for 15-digit int 10.2% faster for 600-digit int Test program that takes 750k ints from [0, 2**32) through stdin: Baseline: 8.114 sec (best of 5 consecutive runs) Modified: 6.774 sec (best of 5 consecutive runs) 19.8% faster NOTE: This patch causes new errors in test_array and test_compile, but it seems that these *should* be failing given the input string for long(), unless I'm missing something: ====================================================================== ERROR: test_repr (__main__.FloatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ====================================================================== ERROR: test_repr (__main__.DoubleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_array.py", line 187, in test_repr self.assertEqual(a, eval(repr(a), {"array": array.array})) ValueError: invalid literal for long(): 10000000000.0 ---------------------------------------------------------------------- test test_compile crashed -- exceptions.ValueError: invalid literal for long(): 90000000000000. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2005-12-20 23:20 Message: Logged In: YES user_id=1115903 I cleaned up the digitlimit vector and test cases now include all bases on [2, 36]. Uploaded as python-mystrtoul5.tgz. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-10-31 19:55 Message: Logged In: YES user_id=31435 This looks pretty good to me -- talk about every trick in the book . Note that the digitlimit vector is too cautious for bases that are powers of 2. For example, it's obvious that any string of 32 bits can't overflow an unsigned long, but the table cuts base 2 off at 31 instead. The formula should use log(2**32, base) instead: "N digits can't overflow" iff base**N-1 < 2**32 iff base**N < 2**32+1 base**N <= 2**32 iff N <= log(2**32, base) Assuming exact calculation of log(2**32, base) then (dubious, really), the floor of that is exactly the maximum safe N. The power-of-2 bases, and base 10, should be added to the tests. We really want to check that _all_ supported bases work, right? ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-10-24 10:26 Message: Logged In: YES user_id=1115903 Thanks, funny_falcon - that corrected the problem with the literals. I also included the change to the digit lookup table. The new patch is attached as python-mystrtoul4.tgz; it passes all tests now on my machine. ---------------------------------------------------------------------- Comment By: funny_falcon (funny_falcon) Date: 2005-10-24 02:07 Message: Logged In: YES user_id=1290388 Instead of: overflowed: /* spool through remaining characters */ while ((c = Py_CHARMASK(*str)) != '\0') str ++; Shoold be while ((c = Py_CHARMASK(*str)) != '\0') { c = digitlookup[c]; if (c < 0 || c >= base) /* non-"digit" character */ break; str++; } And why not static int digitlookup[] = { 37, 37, 37 ...... }; and if (c >= base) break; ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-10-24 00:41 Message: Logged In: YES user_id=1115903 I forgot to add that these results were obtained on a PIIIm 833MHz running Linux 2.4.2, GCC 3.2.2, with the Python 2.5a0 CVS source from about 8pm EST Oct 23, 2005. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335972&group_id=5470 From noreply at sourceforge.net Wed Dec 21 15:05:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Dec 2005 06:05:44 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barran (rbarran) Assigned to: Nobody/Anonymous (nobody) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Richard Barran (rbarran) Date: 2005-12-21 15:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 19:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 12:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-17 18:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Thu Dec 22 15:53:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 06:53:30 -0800 Subject: [Patches] [ python-Patches-1216942 ] Suggested Additional Material for urllib2 docs Message-ID: Patches item #1216942, was opened at 2005-06-08 05:41 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Suggested Additional Material for urllib2 docs Initial Comment: This is some suggested additional material for the urllib2 docs. Particularly the part about error codes and the reason/code attributes of error objects is *missing* from the manual and needed. Also the example showing basic Authentication using password manager/handler/opener may help avoid some confusion. Alternatively you can link to my online tutorials at http://www.voidspace.org.uk/python/articles.shtml#http :-) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-12-22 09:53 Message: Logged In: YES user_id=3066 I'll TeXify. I agree with John about reproducing the response code listing; that's a good place to simply defer to the HTTP spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:01 Message: Logged In: YES user_id=261020 I'm sure doc improvements are welcome here, so thank you :) However, I think you need to 1) split this up into small patches that address very specific issues, and briefly justify each change in the patch submission note on the SF patch tracker 2) present the patches by editing the original .tex source files from src/Doc/lib and then running 'diff -u' or 'svn diff' (it doesn't matter if you can't compile the docs or get the TeX markup wrong, just as long as everybody can see exactly what the intended changes to the text are) Also, one thing that caught my eye on a very brief scan was that the actual response code->name mapping (rather than a note to document the existence of that mapping) shouldn't be reproduced in the docs, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 From noreply at sourceforge.net Thu Dec 22 15:56:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 06:56:47 -0800 Subject: [Patches] [ python-Patches-1388073 ] Make unittest.TestCase easier to subclass Message-ID: Patches item #1388073, was opened at 2005-12-22 09: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=1388073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Make unittest.TestCase easier to subclass Initial Comment: While working on a subclass of unittest.TestCase to support TODO-tests, I found a large number of __-prefixed attributes in TestCase. The presence of these attributes (and methods) meant that I had to copy them over to my new subclass to make python happy. The attached patch converts these __-prefixed attributes to _-prefixed attributes, making it much simpler to subclass TestCase. The patch is against unittest.py from SVN revision 41775. Also attached are "before" and "after" versions of my subclass showing the impact of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388073&group_id=5470 From noreply at sourceforge.net Thu Dec 22 21:38:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 12:38:39 -0800 Subject: [Patches] [ python-Patches-1375417 ] LibRef: reworked chapter organization Message-ID: Patches item #1375417, was opened at 2005-12-07 10:31 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: LibRef: reworked chapter organization Initial Comment: The attached patch is a first cut at reorganizing the chapters of the Library Reference. Three chapters are currently very large: "Miscellaneous Services", 'Generic OS Services' and 'Optional OS Services'. These chapters are broken up into smaller and more focused chapters such as 'file system services' and 'interprocess communication'. This patch isn't ready to be applied yet; I want feedback on the chapter organization before finishing it. Still to do: * Write introductory paragraphs for all of the new chapters * Re-order chapters roughly by importance; this patch creates them in a random order. Difficult corner cases: where should the logging, itertools, functional modules go? The patch leaves them in 'Miscellaneous'. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-12-22 15:38 Message: Logged In: YES user_id=11375 Applied in rev41797. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-08 09:43 Message: Logged In: YES user_id=11375 Attaching a copy of Michael Spencer's reorganization ---------------------------------------------------------------------- Comment By: MIchael Spencer (spencermah) Date: 2005-12-07 17:37 Message: Logged In: YES user_id=1399606 I tried a further re-organization. Results at: http://groups.google.com/group/comp.lang.python/msg/4220f6896602c03c?hl=en& ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2005-12-07 10:33 Message: Logged In: YES user_id=11375 Attaching a copy of the modified lib.tex file; it's probably easier to figure out the new organization by reading this file than by reading the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375417&group_id=5470 From noreply at sourceforge.net Thu Dec 22 23:01:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 14:01:22 -0800 Subject: [Patches] [ python-Patches-1216942 ] Suggested Additional Material for urllib2 docs Message-ID: Patches item #1216942, was opened at 2005-06-08 10:41 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Suggested Additional Material for urllib2 docs Initial Comment: This is some suggested additional material for the urllib2 docs. Particularly the part about error codes and the reason/code attributes of error objects is *missing* from the manual and needed. Also the example showing basic Authentication using password manager/handler/opener may help avoid some confusion. Alternatively you can link to my online tutorials at http://www.voidspace.org.uk/python/articles.shtml#http :-) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-22 22:01 Message: Logged In: YES user_id=261020 Fred, what will you TeXify? Are you waiting for Mike to reply, or were you saying that you'll TeXify what he already submitted? Personally, I'm not happy with the original as-is, foremost because it's not clear how it is intended to fit with the existing docs (there are certainly other problems with the suggested additions, but not much point going into detail before there's a patch). I would be happy to review / edit at least some of the content it if it were presented as patch(es). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-12-22 14:53 Message: Logged In: YES user_id=3066 I'll TeXify. I agree with John about reproducing the response code listing; that's a good place to simply defer to the HTTP spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:01 Message: Logged In: YES user_id=261020 I'm sure doc improvements are welcome here, so thank you :) However, I think you need to 1) split this up into small patches that address very specific issues, and briefly justify each change in the patch submission note on the SF patch tracker 2) present the patches by editing the original .tex source files from src/Doc/lib and then running 'diff -u' or 'svn diff' (it doesn't matter if you can't compile the docs or get the TeX markup wrong, just as long as everybody can see exactly what the intended changes to the text are) Also, one thing that caught my eye on a very brief scan was that the actual response code->name mapping (rather than a note to document the existence of that mapping) shouldn't be reproduced in the docs, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 From noreply at sourceforge.net Thu Dec 22 23:07:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 14:07:06 -0800 Subject: [Patches] [ python-Patches-1216942 ] Suggested Additional Material for urllib2 docs Message-ID: Patches item #1216942, was opened at 2005-06-08 10:41 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Foord (mjfoord) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Suggested Additional Material for urllib2 docs Initial Comment: This is some suggested additional material for the urllib2 docs. Particularly the part about error codes and the reason/code attributes of error objects is *missing* from the manual and needed. Also the example showing basic Authentication using password manager/handler/opener may help avoid some confusion. Alternatively you can link to my online tutorials at http://www.voidspace.org.uk/python/articles.shtml#http :-) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-22 22:07 Message: Logged In: YES user_id=261020 Just to shout it out again: no need for said patches to contain TeX markup!-) Plain text / reST pasted into the existing docs is ok (though making it clear by some means what is a heading and what isn't &c. is obviously desirable). I only want a patch because that would make it clear how the additions are intended to be integrated with the existing docs. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-22 22:01 Message: Logged In: YES user_id=261020 Fred, what will you TeXify? Are you waiting for Mike to reply, or were you saying that you'll TeXify what he already submitted? Personally, I'm not happy with the original as-is, foremost because it's not clear how it is intended to fit with the existing docs (there are certainly other problems with the suggested additions, but not much point going into detail before there's a patch). I would be happy to review / edit at least some of the content it if it were presented as patch(es). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-12-22 14:53 Message: Logged In: YES user_id=3066 I'll TeXify. I agree with John about reproducing the response code listing; that's a good place to simply defer to the HTTP spec. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:01 Message: Logged In: YES user_id=261020 I'm sure doc improvements are welcome here, so thank you :) However, I think you need to 1) split this up into small patches that address very specific issues, and briefly justify each change in the patch submission note on the SF patch tracker 2) present the patches by editing the original .tex source files from src/Doc/lib and then running 'diff -u' or 'svn diff' (it doesn't matter if you can't compile the docs or get the TeX markup wrong, just as long as everybody can see exactly what the intended changes to the text are) Also, one thing that caught my eye on a very brief scan was that the actual response code->name mapping (rather than a note to document the existence of that mapping) shouldn't be reproduced in the docs, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1216942&group_id=5470 From noreply at sourceforge.net Fri Dec 23 00:01:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 15:01:02 -0800 Subject: [Patches] [ python-Patches-1388440 ] add more readline support Message-ID: Patches item #1388440, was opened at 2005-12-22 15:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388440&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Boving (sebbov) Assigned to: Nobody/Anonymous (nobody) Summary: add more readline support Initial Comment: I came accross the need for more GNU readline library support in the python readline module. This patch adds support for 2 extra functions and their doc, get_completion_type() and set_completion_display_matches_function_hook(). The latter allows you to add set a python callback as the readline rl_completion_display_matches function*. I tested the patch against the svn head (2.5) on a RedHat 9 intel system, and against a Python 2.4.2 on an Ubuntu 5.10 intel system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388440&group_id=5470 From noreply at sourceforge.net Fri Dec 23 06:47:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Dec 2005 21:47:18 -0800 Subject: [Patches] [ python-Patches-1388440 ] add more readline support Message-ID: Patches item #1388440, was opened at 2005-12-23 08:01 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388440&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Boving (sebbov) Assigned to: Nobody/Anonymous (nobody) Summary: add more readline support Initial Comment: I came accross the need for more GNU readline library support in the python readline module. This patch adds support for 2 extra functions and their doc, get_completion_type() and set_completion_display_matches_function_hook(). The latter allows you to add set a python callback as the readline rl_completion_display_matches function*. I tested the patch against the svn head (2.5) on a RedHat 9 intel system, and against a Python 2.4.2 on an Ubuntu 5.10 intel system. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-12-23 14:47 Message: Logged In: YES user_id=671362 There's no patch! You have to check the checkbox labeled "Check to Upload and Attach File" to upload a file. Please try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388440&group_id=5470 From noreply at sourceforge.net Fri Dec 23 22:32:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 13:32:41 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 09:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Neal Norwitz (nnorwitz) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-23 13:32 Message: Logged In: YES user_id=33168 Should there be doc changes for LoadError subclassing IOError? Should the re-raise of IOError be changed to raise LoadError? Committed revision 41798. Committed revision 41799. (Misc/NEWS) Committed revision 41800. (2.4) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-05 14:54 Message: Logged In: YES user_id=261020 OK, another patch applied since March causes loaderror_v2.patch to add a class statement which is already present in the patched file. loaderror_v3.patch fixes that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 15:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 12:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 07:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 15:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 10:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 06:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 06:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 06:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 06:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 03:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 10:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 08:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 14:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 08:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Fri Dec 23 22:45:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Dec 2005 13:45:20 -0800 Subject: [Patches] [ python-Patches-1157027 ] cookielib mis-handles RFC 2109 cookies in Netscape mode Message-ID: Patches item #1157027, was opened at 2005-03-04 15:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1157027&group_id=5470 Please note that this 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 Submitted By: John J Lee (jjlee) >Assigned to: Neal Norwitz (nnorwitz) Summary: cookielib mis-handles RFC 2109 cookies in Netscape mode Initial Comment: cookielib treats RFC 2109 cookies as RFC 2965 even when functioning as a pure Netscape protocol implementation (ie. when RFC 2965 handling is disabled by setting a CookiePolicy instance's rfc2965 attribute false). This is not correct: the Netscape cookie protocol, in the absence of RFC 2965 (yes, BTW: RFC 2965 and its unfinished errata say that RFC 2965 and Netscape handling are supposed to interact with each other, in complicated and ill-defined ways), treats RFC 2109 cookies as Netscape cookies. Background: The Netscape protocol is an ad-hoc standard defined by the MSIE and Mozilla browser implementations. A Netscape cookie is one set in the Set-Cookie header with no version cookie-attribute. An RFC 2109 cookie is a one set in the Set-Cookie header with a version cookie-attribute of 1. An RFC 2965 cookie is a one set in the Set-Cookie2 (note the '2') header with a version cookie-attribute of 1. Popular browsers treat RFC 2109 cookies as Netscape cookies (which, ad-hoc as Netscape cookies are, effectively include a few bits and pieces from the 2109 standard). The bug breaks apps like Mailman that (naively or stubbornly) send RFC 2109 cookies. The patch treats RFC 2109 cookies as Netscape cookies if RFC 2965 handling is turned off. (It also removes two no-op lines of code at around line 1304). Test and doc patches are included. 2.4 backport candidate. (The bug was uncovered by the switch, in the patch originally accepted to Python stdlib, to RFC 2965 handling being off by default. Earlier versions of ClientCookie had RFC 2965 off by default.) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-23 13:45 Message: Logged In: YES user_id=33168 Since there were API changes, I did not backport this to 2.4 Committed revision 41802. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-05 14:28 Message: Logged In: YES user_id=261020 Since this didn't get applied in 2.4.1 or 2.4.2, I have uploaded a new patch for 2.5, and deleted the original patch attached to this tracker item. Tests and documentation changes are included in the patch. In addition to fixing the bug described in the original patch comment, this patch (rfc2109-2.patch) adds two new attributes (hence should not be back-ported): 1. Cookie instances have an rfc2109 attribute. This attribute is true if the cookie was received as an RFC 2109 cookie (ie. the cookie arrived in a \mailheader{Set-Cookie} header, and the value of the Version cookie-attribute in that header was 1). 2. DefaultCookiePolicy instances have an rfc2109_as_netscape attribute. Assigning to this attribute allows explicit control over whether RFC 2109 cookies are 'downgraded' to Netscape cookies. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 15:11 Message: Logged In: YES user_id=261020 > (...Earlier versions of ClientCookie had RFC 2965 off by default.) I meant to say: > (...Earlier versions of ClientCookie had RFC 2965 on by default.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1157027&group_id=5470 From noreply at sourceforge.net Mon Dec 26 17:09:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 08:09:51 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Mon Dec 26 17:51:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Dec 2005 08:51:54 -0800 Subject: [Patches] [ python-Patches-1177307 ] UTF-8-Sig codec Message-ID: Patches item #1177307, was opened at 2005-04-05 21:26 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177307&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Martin v. L?wis (loewis) Summary: UTF-8-Sig codec Initial Comment: This patch implements a UTF-8-Sig codec. This codec works like UTF-8 but adds a BOM on writing and skips (at most) one BOM on reading. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-12-26 17:51 Message: Logged In: YES user_id=89016 OK, here's a text that explains what the BOM is used for in various Unicode encodings. I hope that this can be turned into something useful. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-09 20:53 Message: Logged In: YES user_id=21627 The place is right, but I feel this documentation is incomplete still. The library reference should explain somewhere what the difference between utf-8 and utf-8-sig is. Perhaps a footnote could be added. I think I would prefer a separate subsection on the BOM, explaining byte order in UTF-{16,32}, and how the BOM can be used as a magic signature for UTF-8. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-08-09 15:41 Message: Logged In: YES user_id=89016 This version (diff3.txt) of the patch adds a note to Misc/NEWS and a section to Doc/lib/libcodecs.tex. Is this the correct place to add the documentation? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-07 23:51 Message: Logged In: YES user_id=21627 The patch looks fine, but lacks documentation changes. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-05 22:28 Message: Logged In: YES user_id=89016 This second version of the patch will return starting bytes immediately, if they don't look like a BOM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177307&group_id=5470 From noreply at sourceforge.net Tue Dec 27 14:00:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 05:00:13 -0800 Subject: [Patches] [ python-Patches-1391204 ] dict.merge Message-ID: Patches item #1391204, was opened at 2005-12-27 14:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Nobody/Anonymous (nobody) Summary: dict.merge Initial Comment: If you want to update a dictionary with another one, you can simply use update : a = dict(a=1,c=3) b = dict(a=0,b=2) a.update(b) assert a == dict(a=0,b=2,c=3) However, sometimes you want to merge the second dict into the first, all while keeping the values that are already defined in the first. This is useful if you want to insert default values in the dictionary without overriding what is already defined. Currently this can be done in a few different ways, but all are awkward and/or inefficient : a = dict(a=1,c=3) b = dict(a=0,b=2) Method 1: for k in b: if k not in a: a[k] = b[k] Method 2: temp = dict(b) temp.update(a) a = temp This patch adds a merge() method to the dict object, with the same signature and usage as the update() method. Under the hood, it simply uses PyDict_Merge() with the override parameter set to 0 instead of 1. There's nothing new, therefore : the C API already provides this functionality (though it is not used in the dictobject.c scope), so why not expose it ? The result is : a = dict(a=1,c=3) b = dict(a=0,b=2) a.merge(b) assert a == dict(a=1,b=2,c=3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1391204&group_id=5470 From noreply at sourceforge.net Tue Dec 27 17:16:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 08:16:40 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From mala4000 at bol.com.br Tue Dec 27 18:48:15 2005 From: mala4000 at bol.com.br (Roberta Cunha) Date: Tue, 27 Dec 2005 14:48:15 -0300 Subject: [Patches] Cartas Comerciais Message-ID: <20051227174820.70E307909@sankara1.bol.com.br> Cartas Comerciais. Modelos prontos de cartas e e-mails comerciais. Visite o site: http://www.gueb.de/cartascomerciais Cartas Comerciais, E veja alguns dos modelos abaixo: http://www.gueb.de/cartascomerciais * Agradecimentos e condol?ncias * Atestados e Declara??es * Cartas de Cobran?as * Cartas de Reclama??o * Cartas em Ingl?s * Comunicados e Avisos * Convites * Documentos * Emprego * Propostas * Solicita??es e pedidos * Viagem Cartas Comerciais Procura??o Carta de Recomenda??o Convite para Exposi??o ou Feira Cartas Comerciais AGRADECIMENTOS E CONDOL?NCIAS ? Agradecimento de convite e felicita??es; ? Agradecimento e convite para solenidade; ? Agradecimento de mensagem de p?sames; ? Agradecimento de pedido; ? Agradecimento e boas vindas a cliente novo; ? Agradecimento por mensagem de felicita??o; ? Confraterniza??o; ? Congratula??es; ? Cumprimentos por resultados comerciais; ? Felicita??es pessoais; ? P?sames; ? Votos de boas festas Voltar ao topo http://www.gueb.de/cartascomerciais CARTAS DE RECLAMA??O Cartas Comerciais ? Reclama??o de compra de produto; ? Reclama??o por atraso; ? Reclama??o por aumento de pre?o; ? Reclama??o por defici?ncia t?cnica; ? Reclama??o por demora na entrega; ? Reclama??o por diverg?ncia; ? Respostas a reclama??es; Voltar ao topo COMUNICADOS E AVISOS ? Advert?ncia a funcion?rio; ? Aviso de aumento de pre?os; ? Aviso de incorpora??o da empresa; ? Aviso de lan?amento de produto e servi?o; ? Aviso de mudan?a de endere?o; ? Aviso de ocorr?ncia de acidente; ? Aviso de t?rmino de contrato; ? Aviso gen?rico; ? Comunica??o de atraso no envio de mercadorias; ? Comunica??o de devolu??o de duplicata; ? Comunica??o de devolu??o de mercadoria; ? Comunica??o de envio de mercadorias; ? Comunica??o de envio de parte do pedido; ? Comunica??o de extravio de mercadorias; ? Comunica??o de f?rias coletivas; ? Comunica??o de liquida??o de d?bito; ? Comunica??o de novo servi?o de televendas; ? Comunica??o de reuni?o; ? Confirma??o de pedido; ? Resposta ao comunicado de reuni?o; Voltar ao topo Cartas Comerciais http://www.gueb.de/cartascomerciais EMPREGO ? Aviso pr?vio de dispensa de empregado: 1, 2, e 3; ? Carta de recomenda??o; ? Pedido de demiss?o: 1 e 2; ? Solicita??o de emprego: 1, 2 e 3; ? Solicita??o de est?gio; Voltar ao topo Cartas Comerciais ATESTADOS E DECLARA??ES ? Atestado de bons antecedentes; ? Atestado m?dico; ? Declara??o negativa de v?nculo empregat?cio; ? Declara??o para cancelamento de protesto; ? Declara??o para fins escolares; Voltar ao topo Cartas Comerciais CARTAS DE COBRAN?A ? Cartas de cobran?a: 1, 2, 3, 4, 5, 6, 7 e 8; ? Encaminhamento de cobran?a a protesto; ? Oferecimento de servi?o de cobran?a; ? Recebimento de d?bito pendente; Voltar ao topo CARTAS EM INGL?S Cartas Comerciais ? Cancelamento de pedido; ? Carta de demiss?o; ? Carta de refer?ncia; ? Curriculum vitae; ? Pedido de produto: 1 e 2; ? Reclama??o de assinatura de publica??o; ? Remessa de valores; ? Resposta a pedido de produto; ? Resposta a solicita??o de emprego; ? Resposta a solicita??o de informa??es; ? Resposta a solicita??o de pre?os; ? Solicita??o de emprego; ? Solicita??o de informa??es comerciais; ? Solicita??o de licen?a; ? Solicita??o de pre?os; Voltar ao topo Cartas Comerciais CONVITES http://www.gueb.de/cartascomerciais ? Convite para batizado; ? Convite para evento social; ? Convite para exposi??o ou feira; ? Convite para lan?amento de produto; ? Resposta negativa a convite; ? Resposta positiva a convite; Voltar ao topo DOCUMENTOS ? Ata; ? Contrato de loca??o de im?vel; ? Contrato firmado acordo; ? Contrato social; ? Edital de convoca??o; ? Procura??o; ? Recibo de venda de autom?vel; Voltar ao topo PROPOSTAS ? Proposta de abertura de conta corrente; ? Proposta de presta??o de servi?os: 1 e 2; ? Proposta de representa??o comercial: 1 e 2; ? Proposta para ocupa??o de cargo; ? Proposta para recupera??o de clientes; ? Resposta negativa ? proposta de representa??o: 1 e 2; ? Resposta positiva ? proposta de representa??o: 1 e 2; Voltar ao topo http://www.gueb.de/cartascomerciais SOLICITA??E E PEDIDOS ? Pedido de desculpas; ? Pedido de mercadorias; ? Resposta a pedido de carta de apresenta??o; ? Resposta a solicita??o de c?pias de documentos; ? Resposta a solicita??o de or?amento; ? Resposta negativa a solicita??o de informa??es comerciais; Cartas Comerciais ? Resposta positiva a solicita??o de informa??es comerciais; ? Solicita??o de atestado de Idoneidade Financeira; ? Solicita??o de cat?logos de pre?os; ? Solicita??o de cr?dito; ? Solicita??o de informa??es comerciais; ? Solicita??o de informa??es sobre curso; ? Solicita??o de listas de pre?os; ? Solicita??es de refer?ncias pessoais; ? Suspens?o de pedido de mercadoria; Cartas Comerciais Voltar ao topo VIAGEM ? Informa??es sobre requisitos de viagem; ? Pedido de reserva em hotel; ? Recupera??o de bagagem extraviada; ? Reclama??o de maus tratos ? bagagem; ? Recupera??o de objeto esquecido em hotel; ? Reserva de passagens; ? Roteiro tur?stico. http://www.gueb.de/cartascomerciais From noreply at sourceforge.net Tue Dec 27 22:35:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Dec 2005 13:35:21 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 21:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Wed Dec 28 12:09:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 03:09:55 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-28 11:09 Message: Logged In: YES user_id=4771 Thanks for the comments about the comments, I will fix them. I don't understand the note about abstract.c, though. I think you are referring to the change in PyNumber_Add(), but this change is basically a no-op. You might be reading the diff in the wrong direction: it appears to *remove* a check for Py_NotImplemented. However, this check was added in r25556 and r25557 to fix another bug, and this is no longer needed if the four SLOT1() lines go away. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 21:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Wed Dec 28 17:10:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 08:10:15 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2005-12-28 16:10 Message: Logged In: YES user_id=35752 I'm not sure what Py_NotImplemented check you are referring to but I think the patches do the right thing and could be checked in as is. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 11:09 Message: Logged In: YES user_id=4771 Thanks for the comments about the comments, I will fix them. I don't understand the note about abstract.c, though. I think you are referring to the change in PyNumber_Add(), but this change is basically a no-op. You might be reading the diff in the wrong direction: it appears to *remove* a check for Py_NotImplemented. However, this check was added in r25556 and r25557 to fix another bug, and this is no longer needed if the four SLOT1() lines go away. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 21:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Wed Dec 28 17:45:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 08:45:28 -0800 Subject: [Patches] [ python-Patches-1388440 ] add more readline support Message-ID: Patches item #1388440, was opened at 2005-12-22 15:01 Message generated for change (Comment added) made by sebbov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388440&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Boving (sebbov) Assigned to: Nobody/Anonymous (nobody) Summary: add more readline support Initial Comment: I came accross the need for more GNU readline library support in the python readline module. This patch adds support for 2 extra functions and their doc, get_completion_type() and set_completion_display_matches_function_hook(). The latter allows you to add set a python callback as the readline rl_completion_display_matches function*. I tested the patch against the svn head (2.5) on a RedHat 9 intel system, and against a Python 2.4.2 on an Ubuntu 5.10 intel system. ---------------------------------------------------------------------- >Comment By: Sebastien Boving (sebbov) Date: 2005-12-28 08:45 Message: Logged In: YES user_id=1411229 ah, missed that. should now be attached... ---------------------------------------------------------------------- Comment By: Sebastien Boving (sebbov) Date: 2005-12-28 08:45 Message: Logged In: YES user_id=1411229 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2005-12-22 21:47 Message: Logged In: YES user_id=671362 There's no patch! You have to check the checkbox labeled "Check to Upload and Attach File" to upload a file. Please try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388440&group_id=5470 From noreply at sourceforge.net Wed Dec 28 22:07:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 13:07:16 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 17:09 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-28 22:07 Message: Logged In: YES user_id=38388 Haven't looked at the patches, but your comment "The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested." is not quite correct: We have the _testcapimodule.c for doing C API tests. Do you also address the problem I posted to python-dev ? """...the following code could be the cause for leaking a NotImplemented singleton reference: #define SLOT1BINFULL(FUNCNAME, TESTFUNC, SLOTNAME, OPSTR, ROPSTR) \ static PyObject * \ FUNCNAME(PyObject *self, PyObject *other) \ { \ static PyObject *cache_str, *rcache_str; \ int do_other = self->ob_type != other->ob_type && \ other->ob_type->tp_as_number != NULL && \ other->ob_type->tp_as_number->SLOTNAME == TESTFUNC; \ if (self->ob_type->tp_as_number != NULL && \ self->ob_type->tp_as_number->SLOTNAME == TESTFUNC) { \ PyObject *r; \ if (do_other && \ PyType_IsSubtype(other->ob_type, self->ob_type) && \ method_is_overloaded(self, other, ROPSTR)) { \ r = call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ if (r != Py_NotImplemented) \ return r; \ Py_DECREF(r); \ do_other = 0; \ } \ r = call_maybe( \ self, OPSTR, &cache_str, "(O)", other); \ if (r != Py_NotImplemented || \ other->ob_type == self->ob_type) \ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If both types are of the same type, then a NotImplemented returng value would be returned. return r; \ Py_DECREF(r); \ } \ if (do_other) { \ return call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ } \ Py_INCREF(Py_NotImplemented); \ return Py_NotImplemented; \ } """ ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-28 17:10 Message: Logged In: YES user_id=35752 I'm not sure what Py_NotImplemented check you are referring to but I think the patches do the right thing and could be checked in as is. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 12:09 Message: Logged In: YES user_id=4771 Thanks for the comments about the comments, I will fix them. I don't understand the note about abstract.c, though. I think you are referring to the change in PyNumber_Add(), but this change is basically a no-op. You might be reading the diff in the wrong direction: it appears to *remove* a check for Py_NotImplemented. However, this check was added in r25556 and r25557 to fix another bug, and this is no longer needed if the four SLOT1() lines go away. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 22:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 17:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Wed Dec 28 23:17:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 14:17:48 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-28 22:17 Message: Logged In: YES user_id=4771 Thanks for the reminder! It doesn't change the fact that PySequence_InPlace*() is not tested, but indeed now I know where I should add a test for them. About the python-dev post, see my python-dev answer: it's expected of this function to be able to return Py_NotImplemented, as is obvious from the last return statement :-) (Updated patch to come...) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-28 21:07 Message: Logged In: YES user_id=38388 Haven't looked at the patches, but your comment "The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested." is not quite correct: We have the _testcapimodule.c for doing C API tests. Do you also address the problem I posted to python-dev ? """...the following code could be the cause for leaking a NotImplemented singleton reference: #define SLOT1BINFULL(FUNCNAME, TESTFUNC, SLOTNAME, OPSTR, ROPSTR) \ static PyObject * \ FUNCNAME(PyObject *self, PyObject *other) \ { \ static PyObject *cache_str, *rcache_str; \ int do_other = self->ob_type != other->ob_type && \ other->ob_type->tp_as_number != NULL && \ other->ob_type->tp_as_number->SLOTNAME == TESTFUNC; \ if (self->ob_type->tp_as_number != NULL && \ self->ob_type->tp_as_number->SLOTNAME == TESTFUNC) { \ PyObject *r; \ if (do_other && \ PyType_IsSubtype(other->ob_type, self->ob_type) && \ method_is_overloaded(self, other, ROPSTR)) { \ r = call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ if (r != Py_NotImplemented) \ return r; \ Py_DECREF(r); \ do_other = 0; \ } \ r = call_maybe( \ self, OPSTR, &cache_str, "(O)", other); \ if (r != Py_NotImplemented || \ other->ob_type == self->ob_type) \ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If both types are of the same type, then a NotImplemented returng value would be returned. return r; \ Py_DECREF(r); \ } \ if (do_other) { \ return call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ } \ Py_INCREF(Py_NotImplemented); \ return Py_NotImplemented; \ } """ ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-28 16:10 Message: Logged In: YES user_id=35752 I'm not sure what Py_NotImplemented check you are referring to but I think the patches do the right thing and could be checked in as is. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 11:09 Message: Logged In: YES user_id=4771 Thanks for the comments about the comments, I will fix them. I don't understand the note about abstract.c, though. I think you are referring to the change in PyNumber_Add(), but this change is basically a no-op. You might be reading the diff in the wrong direction: it appears to *remove* a check for Py_NotImplemented. However, this check was added in r25556 and r25557 to fix another bug, and this is no longer needed if the four SLOT1() lines go away. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 21:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Thu Dec 29 00:04:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 15:04:30 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Neal Norwitz (nnorwitz) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-12-28 23:04 Message: Logged In: YES user_id=261020 Thanks Neil (and thanks for applying my other cookielib patch). I've attached a doc patch. I don't like to repeat the wording (as the patch does), but it seems necessary here -- do you agree? The re-raise should not be changed, since CookieJar.load() may legitimately raise exactly IOError in addition to LoadError (and was always documented as such). For example, the IOError should be re-raised when the cookies file does not exist. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-23 21:32 Message: Logged In: YES user_id=33168 Should there be doc changes for LoadError subclassing IOError? Should the re-raise of IOError be changed to raise LoadError? Committed revision 41798. Committed revision 41799. (Misc/NEWS) Committed revision 41800. (2.4) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-05 22:54 Message: Logged In: YES user_id=261020 OK, another patch applied since March causes loaderror_v2.patch to add a class statement which is already present in the patched file. loaderror_v3.patch fixes that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 23:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 15:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 18:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Thu Dec 29 00:05:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 15:05:04 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Neal Norwitz (nnorwitz) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-28 23:04 Message: Logged In: YES user_id=261020 Thanks Neil (and thanks for applying my other cookielib patch). I've attached a doc patch. I don't like to repeat the wording (as the patch does), but it seems necessary here -- do you agree? The re-raise should not be changed, since CookieJar.load() may legitimately raise exactly IOError in addition to LoadError (and was always documented as such). For example, the IOError should be re-raised when the cookies file does not exist. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-23 21:32 Message: Logged In: YES user_id=33168 Should there be doc changes for LoadError subclassing IOError? Should the re-raise of IOError be changed to raise LoadError? Committed revision 41798. Committed revision 41799. (Misc/NEWS) Committed revision 41800. (2.4) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-05 22:54 Message: Logged In: YES user_id=261020 OK, another patch applied since March causes loaderror_v2.patch to add a class statement which is already present in the patched file. loaderror_v3.patch fixes that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 23:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 15:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 18:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Thu Dec 29 00:17:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Dec 2005 15:17:28 -0800 Subject: [Patches] [ python-Patches-1117398 ] cookielib LWPCookieJar and MozillaCookieJar exceptions Message-ID: Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Neal Norwitz (nnorwitz) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-12-28 23:17 Message: Logged In: YES user_id=261020 jjlee> and was always documented as such To be precise, it was documented under .revert(). I attach an improved doc patch (loaderror_docs_v2.patch, obsoleting loaderror_docs.patch) that moves that into the .load() method docs, and makes the .revert() docs refer to that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-28 23:04 Message: Logged In: YES user_id=261020 Thanks Neil (and thanks for applying my other cookielib patch). I've attached a doc patch. I don't like to repeat the wording (as the patch does), but it seems necessary here -- do you agree? The re-raise should not be changed, since CookieJar.load() may legitimately raise exactly IOError in addition to LoadError (and was always documented as such). For example, the IOError should be re-raised when the cookies file does not exist. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-23 21:32 Message: Logged In: YES user_id=33168 Should there be doc changes for LoadError subclassing IOError? Should the re-raise of IOError be changed to raise LoadError? Committed revision 41798. Committed revision 41799. (Misc/NEWS) Committed revision 41800. (2.4) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-05 22:54 Message: Logged In: YES user_id=261020 OK, another patch applied since March causes loaderror_v2.patch to add a class statement which is already present in the patched file. loaderror_v3.patch fixes that. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 23:09 Message: Logged In: YES user_id=261020 jjlee> It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) Sorry, FWLIW, it *does* apply cleanly, I just had the wrong -p argument to patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-12-04 20:20 Message: Logged In: YES user_id=261020 Patch loaderror_v2.patch implements MvL's suggestion (see followup 2005-03-04 14:52), and includes tests. It still applies cleanly (except that 'patch' doesn't like the ',v' on the end of the CVS patch filenames) and the tests pass. Can it be committed, and preferably backported to the 2.4 maintenance branch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-05 15:28 Message: Logged In: YES user_id=261020 This comment is not relevant to the patch, just a comment on my own comment: > Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Hmm, that's not true: four bugs might have been picked up if I'd released a final version of the <=2.4 backwards-compatible ClientCookie 0.9 version (with the interface changes from ClientCookie 0.4 to cookielib), then released a ClientCookie 1.0 after Python 2.4 came out (there was enough time without needing to wait for 2.5). That's what I should have done, instead of trying to protect ClientCookie users from two rounds of interface changes. Live and learn, I suppose. OTOH, no guilt on 1117339 or 1028908 (except regret that I was suddenly unable to work on it for a period up to the 2.4 beta release, hence missing deadline to get the latter applied before it was released). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 23:56 Message: Logged In: YES user_id=261020 Revised patch attached. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 18:39 Message: Logged In: YES user_id=261020 Re IOError: OK, I'll submit a revised patch. Yes, I agree on your first para, with hindsight. I attempted to avoid making users change interfaces twice (once for a release of a Python 2.4 candidate, once for 2.4 itself). Stupid idea, especially since the changes (though "minor") touched a lot of code. Even then, I wonder if it would have received any significant testing in practice from people other than me, since people might not have bothered to switch from the backwards-compatible (<=2.4) version. Thanks for your attention to these bugs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:52 Message: Logged In: YES user_id=21627 I see. In retrospect, it might have been best to reject the cookielib for Python 2.4, and wait for it to get a stable interface and implementation. Without the time machine, we have to accept the consequences, though, so we cannot break existing code. Therefore, I now propose that LoadError becomes a subclass a *permanent* subclass of IOError, thus preserving the historical interface. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:40 Message: Logged In: YES user_id=261020 >>> open('bad_cookies.txt', 'w').write("blah") >>> import cookielib >>> mcj = cookielib.MozillaCookieJar(filename="bad_cookies.txt") >>> mcj.load() Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\lib\cookielib.py", line 1727, in load self._really_load(f, filename, ignore_discard, ignore_expires) File "c:\Python24\lib\_MozillaCookieJar.py", line 53, in _really_load raise IOError( IOError: bad_cookies.txt does not look like a Netscape format cookies file >>> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-04 14:27 Message: Logged In: YES user_id=21627 Can you give an example of an invalid cookies file? How does the library respond to it right now? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-03-04 14:16 Message: Logged In: YES user_id=261020 LoadError is not currently not used anywhere. Without LoadError, how would one distinguish (for the purpose of error handling) an error due to, on the one hand, a missing file, insufficient permissions, etc. (IOError) from an error due, on the other hand, to an invalid cookies file (LoadError)? This is already a problem with IOError, of course, but I don't see why we should make it worse. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 11:03 Message: Logged In: YES user_id=21627 Is it true that LoadError is currently not used anywhere? If so, I think it would be best to eliminate this exception, both from the code and the documentation. To support code that might refer to LoadError already, you could make it a synonym to IOError. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 From noreply at sourceforge.net Thu Dec 29 16:59:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 07:59:53 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-29 15:59 Message: Logged In: YES user_id=4771 Improved the comments and checked in as r41842. I have tested PySequence_InPlace*() "manually". I am thinking about adding the in-place operations to the operator module; this should make all these C functions more easily testable. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 22:17 Message: Logged In: YES user_id=4771 Thanks for the reminder! It doesn't change the fact that PySequence_InPlace*() is not tested, but indeed now I know where I should add a test for them. About the python-dev post, see my python-dev answer: it's expected of this function to be able to return Py_NotImplemented, as is obvious from the last return statement :-) (Updated patch to come...) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-28 21:07 Message: Logged In: YES user_id=38388 Haven't looked at the patches, but your comment "The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested." is not quite correct: We have the _testcapimodule.c for doing C API tests. Do you also address the problem I posted to python-dev ? """...the following code could be the cause for leaking a NotImplemented singleton reference: #define SLOT1BINFULL(FUNCNAME, TESTFUNC, SLOTNAME, OPSTR, ROPSTR) \ static PyObject * \ FUNCNAME(PyObject *self, PyObject *other) \ { \ static PyObject *cache_str, *rcache_str; \ int do_other = self->ob_type != other->ob_type && \ other->ob_type->tp_as_number != NULL && \ other->ob_type->tp_as_number->SLOTNAME == TESTFUNC; \ if (self->ob_type->tp_as_number != NULL && \ self->ob_type->tp_as_number->SLOTNAME == TESTFUNC) { \ PyObject *r; \ if (do_other && \ PyType_IsSubtype(other->ob_type, self->ob_type) && \ method_is_overloaded(self, other, ROPSTR)) { \ r = call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ if (r != Py_NotImplemented) \ return r; \ Py_DECREF(r); \ do_other = 0; \ } \ r = call_maybe( \ self, OPSTR, &cache_str, "(O)", other); \ if (r != Py_NotImplemented || \ other->ob_type == self->ob_type) \ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If both types are of the same type, then a NotImplemented returng value would be returned. return r; \ Py_DECREF(r); \ } \ if (do_other) { \ return call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ } \ Py_INCREF(Py_NotImplemented); \ return Py_NotImplemented; \ } """ ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-28 16:10 Message: Logged In: YES user_id=35752 I'm not sure what Py_NotImplemented check you are referring to but I think the patches do the right thing and could be checked in as is. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 11:09 Message: Logged In: YES user_id=4771 Thanks for the comments about the comments, I will fix them. I don't understand the note about abstract.c, though. I think you are referring to the change in PyNumber_Add(), but this change is basically a no-op. You might be reading the diff in the wrong direction: it appears to *remove* a check for Py_NotImplemented. However, this check was added in r25556 and r25557 to fix another bug, and this is no longer needed if the four SLOT1() lines go away. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 21:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Thu Dec 29 18:09:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 09:09:44 -0800 Subject: [Patches] [ python-Patches-1390657 ] NotImplemented->TypeError in __add__ and __mul__ Message-ID: Patches item #1390657, was opened at 2005-12-26 16:09 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented->TypeError in __add__ and __mul__ Initial Comment: This is a fix for bug #1355842, with a comprehensive test checking that implementing a binary special method but returning NotImplemented does indeed cause a TypeError to be raised. In addition to the case reported in #1355842 (x+=y) the test found another case where NotImplemented was just returned (A()*5), a case where an OverflowError or ValueError was raised instead of TypeError (A()*large_integer), and a case where an unexpected AttributeError was raised (5*A()). The proposed patch also reverts the changes done in svn revisions 25556-25557 corresponding to bug #516727, because it makes that fix unnecessary by adopting a more radical approach. All the problems are due to hard-to-control interactions between the various PyTypeObject slots for addition and multiplication (nb_add vs sq_concat, nb_multiply vs sq_repeat). The approach of the present patch is to not define sq_concat, sq_repeat, sq_inplace_concat and sq_inplace_repeat slots *at all* for user-defined types, even if they have __add__ and __mul__ methods. This is the only sane solution I found, specially with respect to the OverflowError/ValueError problem (caused by trying to convert the integer to a C int in order to try to call sq_repeat). It is also consistent with the behavior of instances of old-style classes -- the InstanceType did not define sq_concat and sq_repeat, either. I'll propose a redefinition of operator.concat() and operator.repeat() on python-dev. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-29 17:09 Message: Logged In: YES user_id=4771 Checked in new built-ins operator.ixxx(), with docs and tests. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-29 15:59 Message: Logged In: YES user_id=4771 Improved the comments and checked in as r41842. I have tested PySequence_InPlace*() "manually". I am thinking about adding the in-place operations to the operator module; this should make all these C functions more easily testable. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 22:17 Message: Logged In: YES user_id=4771 Thanks for the reminder! It doesn't change the fact that PySequence_InPlace*() is not tested, but indeed now I know where I should add a test for them. About the python-dev post, see my python-dev answer: it's expected of this function to be able to return Py_NotImplemented, as is obvious from the last return statement :-) (Updated patch to come...) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-28 21:07 Message: Logged In: YES user_id=38388 Haven't looked at the patches, but your comment "The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested." is not quite correct: We have the _testcapimodule.c for doing C API tests. Do you also address the problem I posted to python-dev ? """...the following code could be the cause for leaking a NotImplemented singleton reference: #define SLOT1BINFULL(FUNCNAME, TESTFUNC, SLOTNAME, OPSTR, ROPSTR) \ static PyObject * \ FUNCNAME(PyObject *self, PyObject *other) \ { \ static PyObject *cache_str, *rcache_str; \ int do_other = self->ob_type != other->ob_type && \ other->ob_type->tp_as_number != NULL && \ other->ob_type->tp_as_number->SLOTNAME == TESTFUNC; \ if (self->ob_type->tp_as_number != NULL && \ self->ob_type->tp_as_number->SLOTNAME == TESTFUNC) { \ PyObject *r; \ if (do_other && \ PyType_IsSubtype(other->ob_type, self->ob_type) && \ method_is_overloaded(self, other, ROPSTR)) { \ r = call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ if (r != Py_NotImplemented) \ return r; \ Py_DECREF(r); \ do_other = 0; \ } \ r = call_maybe( \ self, OPSTR, &cache_str, "(O)", other); \ if (r != Py_NotImplemented || \ other->ob_type == self->ob_type) \ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If both types are of the same type, then a NotImplemented returng value would be returned. return r; \ Py_DECREF(r); \ } \ if (do_other) { \ return call_maybe( \ other, ROPSTR, &rcache_str, "(O)", self); \ } \ Py_INCREF(Py_NotImplemented); \ return Py_NotImplemented; \ } """ ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-28 16:10 Message: Logged In: YES user_id=35752 I'm not sure what Py_NotImplemented check you are referring to but I think the patches do the right thing and could be checked in as is. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-28 11:09 Message: Logged In: YES user_id=4771 Thanks for the comments about the comments, I will fix them. I don't understand the note about abstract.c, though. I think you are referring to the change in PyNumber_Add(), but this change is basically a no-op. You might be reading the diff in the wrong direction: it appears to *remove* a check for Py_NotImplemented. However, this check was added in r25556 and r25557 to fix another bug, and this is no longer needed if the four SLOT1() lines go away. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-12-27 21:35 Message: Logged In: YES user_id=35752 Your change to abstract.c that adds "result = binop_type_error(...)" is certainly correct. Py_NotImplemented should not be returned. Small nits: why not remove the SLOT1 lines from typeobject.c instead of commenting them out? If you want to leave them as comments then you should add an explaination as to why they should not be there. Also, I don't personally like having SF issue numbers in comments as I would rather have the comment be self explanatory. Who knows, SF might go away. The changes to PySequence_* look correct to me as well. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-27 16:16 Message: Logged In: YES user_id=4771 Attached a second patch, extending PySequence_Repeat() and PySequence_Concat() to match more precisely their documentation, which says that they should be equivalent to multiplication and addition respectively, at least when the proper arguments are sequences. In 2.4 and HEAD, it works with new-style instances defining __add__ or __mul__, but it does not work with old-style instances. If the concat_repeat_cleanup.diff patch is checked in, then it stops working for new-style instances too. So the sequence_operations.diff patch cleans up the situation by making this work in all cases. Compatibility note: PySequence_Concat/Repeat() are mostly never used in the core; they are essentially only used by operator.concat() and operator.repeat(). Both patches together should thus not break existing code and could be considered as a bug fix. I'd recommend that we check them in both HEAD and the 2.4 branch. The patch also addresses PySequence_InPlaceConcat/Repeat() but without testing them -- they can't be tested from Python, so they are already completely untested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1390657&group_id=5470 From noreply at sourceforge.net Thu Dec 29 18:43:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 09:43:34 -0800 Subject: [Patches] [ python-Patches-1379023 ] weakref callbacks are called only if the weakref is alive Message-ID: Patches item #1379023, was opened at 2005-12-12 21:34 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: weakref callbacks are called only if the weakref is alive Initial Comment: Weak reference objects have an optional callback argument, which is a function that is called when the original object is killed. This function is called only if the created weakref object is still alive. This fact isn't mentioned in the documentation - this patch mentions it. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-29 17:43 Message: Logged In: YES user_id=4771 Checked in as r41846. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1379023&group_id=5470 From noreply at sourceforge.net Thu Dec 29 19:02:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 10:02:07 -0800 Subject: [Patches] [ python-Patches-1367711 ] Remove usage of UserDict from os.py Message-ID: Patches item #1367711, was opened at 2005-11-27 20:18 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Remove usage of UserDict from os.py Initial Comment: This patch removes UserDict usage from os.py. It uses the new dict base class instead of UserDict. Patch was generated against Revision 41544 of python subersion repository. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-12-29 18:02 Message: Logged In: YES user_id=4771 Subclassing 'dict' to modify some behavior only works more or less in CPython. There are a lot of (admitedly convoluted) ways to get unexpected effects, where the original methods are called instead of the overridden ones. And it's not future-proof: if new methods are added to 'dict' in the future, say a merge() similar to update() but not replacing existing keys, then they will need to be added to that subclass as well, or the method will misbehave. The advantage of UserDict is to guard against all these problems. For example, with the patch: exec "global a; a=5" in os.environ stores the key 'a' directly in os.environ, bypassing the custom __setitem__(). With UserDict instead, we get an explicit error. This is more a joke, but the new-methods-appearing-later problem is more serious IMHO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 From noreply at sourceforge.net Thu Dec 29 22:19:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 13:19:56 -0800 Subject: [Patches] [ python-Patches-1393157 ] Optional second argument for startfile Message-ID: Patches item #1393157, was opened at 2005-12-29 22:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Optional second argument for startfile Initial Comment: An optional second argument for os.startfile could be used to invoke 'verbs' other than the default on a file. For example, os.startfile("myfile.pdb", "print") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393157&group_id=5470 From noreply at sourceforge.net Thu Dec 29 22:22:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Dec 2005 13:22:48 -0800 Subject: [Patches] [ python-Patches-1393157 ] Optional second argument for startfile Message-ID: Patches item #1393157, was opened at 2005-12-29 22:19 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Optional second argument for startfile Initial Comment: An optional second argument for os.startfile could be used to invoke 'verbs' other than the default on a file. For example, os.startfile("myfile.pdb", "print") ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2005-12-29 22:22 Message: Logged In: YES user_id=11105 I meant os.startfile("myfile.pdf", "print"). Sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393157&group_id=5470 From noreply at sourceforge.net Fri Dec 30 16:14:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Dec 2005 07:14:29 -0800 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 10:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Sat Dec 31 01:50:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Dec 2005 16:50:38 -0800 Subject: [Patches] [ python-Patches-1388073 ] Make unittest.TestCase easier to subclass Message-ID: Patches item #1388073, was opened at 2005-12-22 09:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Make unittest.TestCase easier to subclass Initial Comment: While working on a subclass of unittest.TestCase to support TODO-tests, I found a large number of __-prefixed attributes in TestCase. The presence of these attributes (and methods) meant that I had to copy them over to my new subclass to make python happy. The attached patch converts these __-prefixed attributes to _-prefixed attributes, making it much simpler to subclass TestCase. The patch is against unittest.py from SVN revision 41775. Also attached are "before" and "after" versions of my subclass showing the impact of the patch. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-12-30 19:50 Message: Logged In: YES user_id=6380 While I haven't reviewed the code, I am +1 on the intent of the patch. Subclassing TestCase (and other unittest classes!) is often a pain due to too much abstraction. (In retrospect, unittest.py is really way too close a translation of the Java junit package. Too bad.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1388073&group_id=5470