From noreply at sourceforge.net Wed Feb 1 11:27:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 02:27:31 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-02-01 05:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Wed Feb 1 12:00:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 03:00:44 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 14:48 Message generated for change (Comment added) made by pete_forman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-02-01 11:00 Message: Logged In: YES user_id=315964 I would contend that UNIX file permissions are not compatible with MS-DOS though it is possible that PKZIP 2.04g might read them and convert them to an approximation. I would hope that an unzipping program would ignore any file type code that it did not know how to interpret. The ZIP spec explicitly says the the external file attributes are set to zero in the case where input is from standard input. I infer from that that an unzipper should at least be able to extract the bytes of a file. Rather than argue over fine points of interpretation I think that we should take the pragmatic view that a ZIP archive is most likely to be unzipped on the same type of file system that it was created on. The file system code is indeed more complicated. Setting one type for the archive is limiting. It ought to be set for each member. And yes, it should be file system rather than OS. unzip does honor the file mode. External file attributes must be interpreted according to 'version made by'. It does have options such as '-X restore UID/GID info' but those control how much metadata is unpacked, not override incorrect fields. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-31 20:36 Message: Logged In: YES user_id=21627 I think it is more complicated than that. In version 6.2.2, a value of 19 is assigned to OS/X. There might also be cases when 10 (Windows NTFS) is the right answer; it appears they look at the file system rather than the operating system. HOWEVER, it also says that the value should be 0 if the external file attributes are compatible with DOS and pkzip 2.04g. Perhaps it is a bug in unzip that it doesn't honor the file mode? ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-01-26 16:49 Message: Logged In: YES user_id=315964 The merged patch looks good. One extra comment that I'd made was that if os.name is 'java' then a further query of java.lang.System.getProperty("os.name") might be in order. The string returned from that is 'Linux', 'Windows XP' and 'SunOS' on the platforms I can test. A quick search turned up this page: http://lopica.sourceforge.net/os.html On that basis I'd propose a rule that if the Java os.name starts with 'Windows' or 'OS/2' then use 0; if it starts with 'Mac OS' then 7; else 3. Perhaps someone with 'Mac OS X' could pronounce whether it ought to be 3 (UNIX) or 7 (Macintosh). Comments from Jython experts welcome as well. The spec for the ZIP file format is at PKWARE. http://www.pkware.com/business_and_developers/developer/ popups/appnote.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 10:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Wed Feb 1 17:32:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 08:32:38 -0800 Subject: [Patches] [ python-Patches-1417555 ] have SimpleHTTPServer return last-modified headers Message-ID: Patches item #1417555, was opened at 2006-01-28 14:24 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 Please note that this 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: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: have SimpleHTTPServer return last-modified headers Initial Comment: This patch modifies the SimpleHTTPServer to serve Last-Modified headers with its responses, which allows browsers to cache the result, preventing annoying reloads of image files every time you view a page, and so on. Fixes 1417554. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-02-01 11:32 Message: Logged In: YES user_id=764593 If the server doesn't handle the If-Modified-Since header on requests, does this really help much? (I suppose it does give browsers something to use as a heuristic.) But adding that to Simple doesn't really make sense. Adding it to BaseHTTPServer might. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 From noreply at sourceforge.net Wed Feb 1 19:04:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 10:04:24 -0800 Subject: [Patches] [ python-Patches-1417555 ] have SimpleHTTPServer return last-modified headers Message-ID: Patches item #1417555, was opened at 2006-01-28 13:24 Message generated for change (Comment added) made by aaronsw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 Please note that this 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: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: have SimpleHTTPServer return last-modified headers Initial Comment: This patch modifies the SimpleHTTPServer to serve Last-Modified headers with its responses, which allows browsers to cache the result, preventing annoying reloads of image files every time you view a page, and so on. Fixes 1417554. ---------------------------------------------------------------------- >Comment By: Aaron Swartz (aaronsw) Date: 2006-02-01 12:04 Message: Logged In: YES user_id=122141 Yes, it does help. RFC 2616 (HTTP/1.1 spec) says "HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time" and indeed major browsers and caches actually do this. Why doesn't it make sense to add this to SimpleHTTPServer? SimpleHTTPServer serves files from disk; this patch grabs the last-modified time for those files. It certainly wouldn't fit in BaseHTTP -- how would it know what the Last-Modified time would be? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-02-01 10:32 Message: Logged In: YES user_id=764593 If the server doesn't handle the If-Modified-Since header on requests, does this really help much? (I suppose it does give browsers something to use as a heuristic.) But adding that to Simple doesn't really make sense. Adding it to BaseHTTPServer might. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 From noreply at sourceforge.net Wed Feb 1 19:25:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 10:25:28 -0800 Subject: [Patches] [ python-Patches-1421726 ] Fix "be be" documentation typo in lang ref Message-ID: Patches item #1421726, was opened at 2006-02-01 19: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=1421726&group_id=5470 Please note that this 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: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: Fix "be be" documentation typo in lang ref Initial Comment: In the language reference docs is a little typo which the patch (against SVN 42206) fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1421726&group_id=5470 From noreply at sourceforge.net Wed Feb 1 20:15:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 11:15:09 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 18:21 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-02-01 11:15 Message: Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 02:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 04:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From j.chidanti-malunga.s06 at Cranfield.ac.uk Wed Feb 1 20:13:08 2006 From: j.chidanti-malunga.s06 at Cranfield.ac.uk (Joseph Chidanti-Malunga) Date: Wed, 1 Feb 2006 19:13:08 -0000 Subject: [Patches] [ python-Patches-780595 ] Fix zip file header format in zipfile.py Message-ID: <58EDF8C6A8718C42B4DEB344E6E8EB0D0382FD15@silmail1.silsoe.cranfield.ac.uk> I have a corrupt zip file. How cao I fix it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20060201/360670ee/attachment.html From noreply at sourceforge.net Wed Feb 1 20:59:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 11:59:22 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 14:59 Message: Logged In: YES user_id=80475 I am strongly against the broad expansion of this module until it has lived for some time as a successful, mature, well-loved stand-alone module. Each addition needs to be fully thought-out in terms of use cases and evaluated for clarity/efficacy against existing Python solutions. At some point, there was a substantial discussion on just the compose() function. While it seems basic to functional programming, it was found not to be necessary, and not represent much of an improvement over a simple lambda expression. Also, a number of folks have difficulty remembering whether compose(f,g) means f(g(x)) or g(f(x)). Also, some of these entries duplicate those in the itertools module. It is not in Python's best interests to provide several ways of doing the same thing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-02-01 14:15 Message: Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 05:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Wed Feb 1 23:16:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 14:16:03 -0800 Subject: [Patches] [ python-Patches-900744 ] catch invalid chunk length in httplib read routine Message-ID: Patches item #900744, was opened at 2004-02-20 00:14 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 Please note that this 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: Wummel (calvin) Assigned to: Georg Brandl (birkenfeld) Summary: catch invalid chunk length in httplib read routine Initial Comment: In HTTPResponse._read_chunked the chunk length is not checked to be a valid integer, and a ValueError will be raised in such a case. The attached patch catches ValueError (which should not normally happen, so this try:except: is reasonably fast), and raises IncompleteRead exception instead. I have no test case for this yet, but am trying to construct one :) ---------------------------------------------------------------------- >Comment By: Wummel (calvin) Date: 2006-02-01 23:16 Message: Logged In: YES user_id=9205 I attached a simple testcase that triggers the bug. IMHO this patch should be applied for Python 2.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-19 03:07 Message: Logged In: YES user_id=80475 Technically, the patch is fine and it is the way the code should have been written in the first place. Please bring-up on python-dev to determine whether it should be done. I can imagine that a fair amount of existing code has through trial and error discovered the ValueError and chosen to catch that. Changing the exception may unnecessarily break people's code. Sometimes we take that step when it needs to be done, but there should be a good pay-off and, in this case, I don't see it. You may also want to mention it on comp.lang.python to see if anyone cares If the patch goes forward, see if you can mock-up a test that triggers the exception so we have a good unittest. In anycase, this should not be backported (we avoid giving people reasons to not upgrade). ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-18 21:34 Message: Logged In: YES user_id=1188172 Attaching patch which does what agwego said (httplib-chunked.diff). Please review. ---------------------------------------------------------------------- Comment By: agwego (agwego) Date: 2005-02-28 17:53 Message: Logged In: YES user_id=1228982 I've run into this problem in conjunction with mod_python 3.1.4 (and although the problem is caused in mod_python) my python skills aren't up to the task. Which leaves me with fixing httplib. Although the above patch works when it comes to end of file situations, I think it would be better to return what has been consumed so far and leave it at that. A few lines down there's a comment about consuming trailers, this is the case that is tripping up httplib as far as I can tell. This is happening in Python 2.3.4. --- packages/Python-2.3.4/Lib/httplib.py Sun Nov 2 11:51:38 2003 +++ httplib.py Mon Feb 28 11:26:48 2005 @@ -423,7 +423,11 @@ i = line.find(';') if i >= 0: line = line[:i] # strip chunk-extensions - chunk_left = int(line, 16) + try: + chunk_left = int(line, 16) + except ValueError, msg: + self.close() + return value if chunk_left == 0: break if amt is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 From noreply at sourceforge.net Wed Feb 1 23:22:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 14:22:11 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-02-01 17:22 Message: Logged In: YES user_id=1344176 As stated in an earlier comment, I had already noticed the duplication and removed the relevant functions from my patch. The current member list is foldr, foldl, partial, flip, compose, id, scanl and scanr. All of these are implemented in C, removing the need for the special instructions outlined in the original message body. Is it necessary to go through the PEP process to see any of these members included in the module? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 14:59 Message: Logged In: YES user_id=80475 I am strongly against the broad expansion of this module until it has lived for some time as a successful, mature, well-loved stand-alone module. Each addition needs to be fully thought-out in terms of use cases and evaluated for clarity/efficacy against existing Python solutions. At some point, there was a substantial discussion on just the compose() function. While it seems basic to functional programming, it was found not to be necessary, and not represent much of an improvement over a simple lambda expression. Also, a number of folks have difficulty remembering whether compose(f,g) means f(g(x)) or g(f(x)). Also, some of these entries duplicate those in the itertools module. It is not in Python's best interests to provide several ways of doing the same thing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-02-01 14:15 Message: Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 05:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Thu Feb 2 00:09:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 15:09:25 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 18:09 Message: Logged In: YES user_id=80475 If you want to force this through over my objections, a PEP is a way to do it. Also, you can start a conversation on comp.lang.python, marshal support, and then take it to python-dev and ask for Guido to pronounce on it. However, do consider that there may be merit to my suggestion to first offer it as a third-party module. Then, if it is wildly successful, popular, and bug-free, there will be a better case for adding it to the standard library. At the very least, there should be an exercise to scan volumes of real-world code and find-out how often code would be improved by having these functional constructs. I think you will find that several of the functions are only of academic interest in a Python context. The existing language is already very accommodating. List comps and genexps reduce the need for functional constructs -- in particular, they allow arbitrary expressions and allow the programmer to avoid embedded lambdas and calls to the operator module. Also, do consider that these functions can be hard to use because it is difficult to remember the argument order, processing sequence, and handling of end-cases. That is why Guido and so many others hold reduce() in such low regard. Similar thoughts apply to foldr() and foldl(). I sense a desire to force this through because a) it can be done and b) these constructs have been successful in other languages. I do not sense a motivation based on user needs or the inability of the existing language to be able to solve certain classes of problems. To some degree, this programming style is at odds with the language and its goals for readability. A recurring design premise for Python is that is easier to remember how to compose or flip using pure Python than it is to learn and remember where to find a pre-made version in some module somewhere. These tools are so simple that it is hard to argue that they add any value at all. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 17:22 Message: Logged In: YES user_id=1344176 As stated in an earlier comment, I had already noticed the duplication and removed the relevant functions from my patch. The current member list is foldr, foldl, partial, flip, compose, id, scanl and scanr. All of these are implemented in C, removing the need for the special instructions outlined in the original message body. Is it necessary to go through the PEP process to see any of these members included in the module? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 14:59 Message: Logged In: YES user_id=80475 I am strongly against the broad expansion of this module until it has lived for some time as a successful, mature, well-loved stand-alone module. Each addition needs to be fully thought-out in terms of use cases and evaluated for clarity/efficacy against existing Python solutions. At some point, there was a substantial discussion on just the compose() function. While it seems basic to functional programming, it was found not to be necessary, and not represent much of an improvement over a simple lambda expression. Also, a number of folks have difficulty remembering whether compose(f,g) means f(g(x)) or g(f(x)). Also, some of these entries duplicate those in the itertools module. It is not in Python's best interests to provide several ways of doing the same thing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-02-01 14:15 Message: Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 05:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Thu Feb 2 01:53:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 16:53:10 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-02-01 19:53 Message: Logged In: YES user_id=1344176 I'm not going to force it; somehow pissing off the python-dev crowd doesn't seem like the best route ;) This work is based more on scratching an itch of mine, a desire for more functional-style tools in Python. In any case, I've just released version 0.5 of just such a third-party module to PyPI (the name is "functional"). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 18:09 Message: Logged In: YES user_id=80475 If you want to force this through over my objections, a PEP is a way to do it. Also, you can start a conversation on comp.lang.python, marshal support, and then take it to python-dev and ask for Guido to pronounce on it. However, do consider that there may be merit to my suggestion to first offer it as a third-party module. Then, if it is wildly successful, popular, and bug-free, there will be a better case for adding it to the standard library. At the very least, there should be an exercise to scan volumes of real-world code and find-out how often code would be improved by having these functional constructs. I think you will find that several of the functions are only of academic interest in a Python context. The existing language is already very accommodating. List comps and genexps reduce the need for functional constructs -- in particular, they allow arbitrary expressions and allow the programmer to avoid embedded lambdas and calls to the operator module. Also, do consider that these functions can be hard to use because it is difficult to remember the argument order, processing sequence, and handling of end-cases. That is why Guido and so many others hold reduce() in such low regard. Similar thoughts apply to foldr() and foldl(). I sense a desire to force this through because a) it can be done and b) these constructs have been successful in other languages. I do not sense a motivation based on user needs or the inability of the existing language to be able to solve certain classes of problems. To some degree, this programming style is at odds with the language and its goals for readability. A recurring design premise for Python is that is easier to remember how to compose or flip using pure Python than it is to learn and remember where to find a pre-made version in some module somewhere. These tools are so simple that it is hard to argue that they add any value at all. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 17:22 Message: Logged In: YES user_id=1344176 As stated in an earlier comment, I had already noticed the duplication and removed the relevant functions from my patch. The current member list is foldr, foldl, partial, flip, compose, id, scanl and scanr. All of these are implemented in C, removing the need for the special instructions outlined in the original message body. Is it necessary to go through the PEP process to see any of these members included in the module? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 14:59 Message: Logged In: YES user_id=80475 I am strongly against the broad expansion of this module until it has lived for some time as a successful, mature, well-loved stand-alone module. Each addition needs to be fully thought-out in terms of use cases and evaluated for clarity/efficacy against existing Python solutions. At some point, there was a substantial discussion on just the compose() function. While it seems basic to functional programming, it was found not to be necessary, and not represent much of an improvement over a simple lambda expression. Also, a number of folks have difficulty remembering whether compose(f,g) means f(g(x)) or g(f(x)). Also, some of these entries duplicate those in the itertools module. It is not in Python's best interests to provide several ways of doing the same thing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-02-01 14:15 Message: Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 05:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Thu Feb 2 04:19:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 19:19:31 -0800 Subject: [Patches] [ python-Patches-1412451 ] Fill out the functional module Message-ID: Patches item #1412451, was opened at 2006-01-22 21:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fill out the functional module Initial Comment: This patch is an expansion of my earlier patch, #1410119, and should be considered to supersede it. This patch fixes a reference leak in the earlier implementation of foldr. The reference leak was tricky to trigger, but existed. In addition, this patch breaks the functional module into two parts: Modules/_functionalmodule.c and Lib/functional.py. The latter is for list-producing functions which are better implemented as generators (to make them lazier), while the former is reserved for non-list-producing functions, written in C for speed. Lib/functional.py imports the `_functional` module generated from Modules/_functionalmodule.c. The total contents of the functional module: + compose + concat + concatMap + cycle + drop + dropWhile + flip + foldl + foldl1 + foldr + foldr1 + id + iterate + partial + repeat + scanl + scanl1 + scanr + scanr1 + take + takeWhile In addition to a full test-suite and latex-formatted documentation for all functions, this patch also adds a functional/ directory to Demo/ and populates it with examples. After applying this patch, the existing Modules/functionalmodule.c should be removed and replaced with the attached _functionalmodule.c (sorry, I couldn't figure out how to make this show up in an svn diff reliably). The patch is against svn revision 42148. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 22:19 Message: Logged In: YES user_id=80475 Good luck with the module. Let us know how it fares in the real-world, whether it turns out to be indispensible or just a curiousity. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 19:53 Message: Logged In: YES user_id=1344176 I'm not going to force it; somehow pissing off the python-dev crowd doesn't seem like the best route ;) This work is based more on scratching an itch of mine, a desire for more functional-style tools in Python. In any case, I've just released version 0.5 of just such a third-party module to PyPI (the name is "functional"). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 18:09 Message: Logged In: YES user_id=80475 If you want to force this through over my objections, a PEP is a way to do it. Also, you can start a conversation on comp.lang.python, marshal support, and then take it to python-dev and ask for Guido to pronounce on it. However, do consider that there may be merit to my suggestion to first offer it as a third-party module. Then, if it is wildly successful, popular, and bug-free, there will be a better case for adding it to the standard library. At the very least, there should be an exercise to scan volumes of real-world code and find-out how often code would be improved by having these functional constructs. I think you will find that several of the functions are only of academic interest in a Python context. The existing language is already very accommodating. List comps and genexps reduce the need for functional constructs -- in particular, they allow arbitrary expressions and allow the programmer to avoid embedded lambdas and calls to the operator module. Also, do consider that these functions can be hard to use because it is difficult to remember the argument order, processing sequence, and handling of end-cases. That is why Guido and so many others hold reduce() in such low regard. Similar thoughts apply to foldr() and foldl(). I sense a desire to force this through because a) it can be done and b) these constructs have been successful in other languages. I do not sense a motivation based on user needs or the inability of the existing language to be able to solve certain classes of problems. To some degree, this programming style is at odds with the language and its goals for readability. A recurring design premise for Python is that is easier to remember how to compose or flip using pure Python than it is to learn and remember where to find a pre-made version in some module somewhere. These tools are so simple that it is hard to argue that they add any value at all. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 17:22 Message: Logged In: YES user_id=1344176 As stated in an earlier comment, I had already noticed the duplication and removed the relevant functions from my patch. The current member list is foldr, foldl, partial, flip, compose, id, scanl and scanr. All of these are implemented in C, removing the need for the special instructions outlined in the original message body. Is it necessary to go through the PEP process to see any of these members included in the module? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-01 14:59 Message: Logged In: YES user_id=80475 I am strongly against the broad expansion of this module until it has lived for some time as a successful, mature, well-loved stand-alone module. Each addition needs to be fully thought-out in terms of use cases and evaluated for clarity/efficacy against existing Python solutions. At some point, there was a substantial discussion on just the compose() function. While it seems basic to functional programming, it was found not to be necessary, and not represent much of an improvement over a simple lambda expression. Also, a number of folks have difficulty remembering whether compose(f,g) means f(g(x)) or g(f(x)). Also, some of these entries duplicate those in the itertools module. It is not in Python's best interests to provide several ways of doing the same thing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-02-01 14:15 Message: Logged In: YES user_id=357491 Do note that the function names do not follow the naming convention specified in PEP 8. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 05:27 Message: Logged In: YES user_id=1344176 I've updated functional.patch to remove functions that are already handled in itertools. The remaining functions which had been implemented in Python have now all been recoded in C. All functions have seen implementation improvements since the last version of the patch. This patch removes the need for the icky "manually add _functionalmodule.c" part of the original patching instructions. No special actions are necessary now. The patch is against svn revision 42219. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-23 07:55 Message: Logged In: YES user_id=1344176 I've broken the main functional.patch into two subpatches. demo.patch creates and populates the Demo/functional/ directory, while functional.patch does all the rest. Both patches are updated to r42155. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412451&group_id=5470 From noreply at sourceforge.net Thu Feb 2 05:40:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 20:40:22 -0800 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 07:14 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 20:40 Message: Logged In: YES user_id=971153 The patch works for me. I think the feature is desirable. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 13:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Thu Feb 2 05:51:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Feb 2006 20:51:33 -0800 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 07:14 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 20:51 Message: Logged In: YES user_id=971153 one suggestion though: do we really need 'restart' alias? The main problem is that gdb uses "restart" for a very different purpose (restarting a program from a known state)..And we probably shouldn't deviate from gdb's command set unless we have to. Also I think we should not pollute the command space without a real need...(a similar argument could be made agaist "ru" abbreviation as well, but it's of lesser importance) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-01 20:40 Message: Logged In: YES user_id=971153 The patch works for me. I think the feature is desirable. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 13:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Thu Feb 2 12:26:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Feb 2006 03:26:42 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 11:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Thu Feb 2 13:02:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Feb 2006 04:02:48 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 11:26 Message generated for change (Comment added) made by csuwi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- >Comment By: Ben Bell (csuwi) Date: 2006-02-02 12:02 Message: Logged In: YES user_id=145982 The previous patch was a little lazy. I've now taken the opportunity to add module doc and fix the two compile time warnings as well. New diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Thu Feb 2 15:09:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Feb 2006 06:09:13 -0800 Subject: [Patches] [ python-Patches-1417555 ] have SimpleHTTPServer return last-modified headers Message-ID: Patches item #1417555, was opened at 2006-01-28 14:24 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 Please note that this 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: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: have SimpleHTTPServer return last-modified headers Initial Comment: This patch modifies the SimpleHTTPServer to serve Last-Modified headers with its responses, which allows browsers to cache the result, preventing annoying reloads of image files every time you view a page, and so on. Fixes 1417554. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-02-02 09:09 Message: Logged In: YES user_id=764593 Sorry, I wasn't clear enough. Adding the Last-Modified to responses created by SimpleServer makes perfect sense. I had been (wrongly) thinking it was only useful in conjunction with a possible "304 Not Modified" response. Adding the 304 logic to a "simple" server may not fit, but adding it to BaseServer (and calling it from SimpleServer, which has the file's timestamp) would be reasonable. ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2006-02-01 13:04 Message: Logged In: YES user_id=122141 Yes, it does help. RFC 2616 (HTTP/1.1 spec) says "HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time" and indeed major browsers and caches actually do this. Why doesn't it make sense to add this to SimpleHTTPServer? SimpleHTTPServer serves files from disk; this patch grabs the last-modified time for those files. It certainly wouldn't fit in BaseHTTP -- how would it know what the Last-Modified time would be? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-02-01 11:32 Message: Logged In: YES user_id=764593 If the server doesn't handle the If-Modified-Since header on requests, does this really help much? (I suppose it does give browsers something to use as a heuristic.) But adding that to Simple doesn't really make sense. Adding it to BaseHTTPServer might. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1417555&group_id=5470 From noreply at sourceforge.net Thu Feb 2 23:00:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Feb 2006 14:00:13 -0800 Subject: [Patches] [ python-Patches-1421726 ] Fix "be be" documentation typo in lang ref Message-ID: Patches item #1421726, was opened at 2006-02-01 19:25 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1421726&group_id=5470 Please note that this 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: Wummel (calvin) >Assigned to: Fredrik Lundh (effbot) Summary: Fix "be be" documentation typo in lang ref Initial Comment: In the language reference docs is a little typo which the patch (against SVN 42206) fixes. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-02-02 23:00 Message: Logged In: YES user_id=38376 Fixed in SVN. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1421726&group_id=5470 From noreply at sourceforge.net Sat Feb 4 12:34:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 03:34:51 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 12:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 12:34 Message: Logged In: YES user_id=21627 Can you please attach the new patch to the report? ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-02 13:02 Message: Logged In: YES user_id=145982 The previous patch was a little lazy. I've now taken the opportunity to add module doc and fix the two compile time warnings as well. New diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Sat Feb 4 15:51:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 06:51:49 -0800 Subject: [Patches] [ python-Patches-1424065 ] The email package needs an "application" type Message-ID: Patches item #1424065, was opened at 2006-02-04 15:39 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1424065&group_id=5470 Please note that this 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: Keith Dart (kdart) Assigned to: Barry A. Warsaw (bwarsaw) Summary: The email package needs an "application" type Initial Comment: The email package lacks a top-level MIME class for "application/*" MIME types. Attached to this bug is one that you might want to include. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1424065&group_id=5470 From noreply at sourceforge.net Sat Feb 4 16:32:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 07:32:39 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 11:26 Message generated for change (Comment added) made by csuwi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- >Comment By: Ben Bell (csuwi) Date: 2006-02-04 15:32 Message: Logged In: YES user_id=145982 Sorry, uploaded this time ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 11:34 Message: Logged In: YES user_id=21627 Can you please attach the new patch to the report? ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-02 12:02 Message: Logged In: YES user_id=145982 The previous patch was a little lazy. I've now taken the opportunity to add module doc and fix the two compile time warnings as well. New diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Sat Feb 4 20:14:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 11:14:09 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 12:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 20:14 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as revision 42235. In the future, please remember the following details: - use PyDoc_STRVAR for documentation variables - add changes to the tex documentation as well ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-04 16:32 Message: Logged In: YES user_id=145982 Sorry, uploaded this time ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 12:34 Message: Logged In: YES user_id=21627 Can you please attach the new patch to the report? ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-02 13:02 Message: Logged In: YES user_id=145982 The previous patch was a little lazy. I've now taken the opportunity to add module doc and fix the two compile time warnings as well. New diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Sat Feb 4 23:45:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 14:45:43 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 03:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-04 14:45 Message: Logged In: YES user_id=33168 Ben, could you also update Lib/test/test_nis.py to test the new code? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 11:14 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as revision 42235. In the future, please remember the following details: - use PyDoc_STRVAR for documentation variables - add changes to the tex documentation as well ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-04 07:32 Message: Logged In: YES user_id=145982 Sorry, uploaded this time ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 03:34 Message: Logged In: YES user_id=21627 Can you please attach the new patch to the report? ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-02 04:02 Message: Logged In: YES user_id=145982 The previous patch was a little lazy. I've now taken the opportunity to add module doc and fix the two compile time warnings as well. New diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Sun Feb 5 07:01:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 22:01:18 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 00:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this 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: Ralf Schmitt (titty) >Assigned to: Neal Norwitz (nnorwitz) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-04 22:01 Message: Logged In: YES user_id=33168 I modified the patch some. Removed include since that didn't seem necessary. Changed the #ifdef slightly. Modified comments. I now understand that anonymous memory was allowed on Unix before (in 2.3 and pre 2.4.2). I backported the non-feature enhancements of this patch (not dup()ing -1). So 2.4.3 should work like 2.4.1 and earlier. It would be great if you can test out 2.5 and 2.4.3 from SVN. Committed revision 42244. Committed revision 42245. (2.4) ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-18 01:16 Message: Logged In: YES user_id=17929 Thanks for the insight. And yes, I forgot to check that little box. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:24 Message: Logged In: YES user_id=33168 To answer your question: > Aren't the tests being run before release on all major platforms? It's difficult to answer. I think generally the answer is yes, but it all depends on volunteers. We are currently running tests on every checkin: http://www.python.org/dev/buildbot/ for both HEAD and 2.4 branch. BuildBot is a relatively recent addition though. On OS X 10.3, we aren't having a problem with mmap(). Various developers I know use OS X, not sure which versions of OS X though. -- General comments about the patch: For any solution, we should strive to make it available if possible (with reason) on all platforms. We should attempt to have all versions of Python behave similarly. (I'm not trying to imply you aren't working in this direction, it seems like you are.) I only notice one patch attached. Have you been deleting the others or did you forget to check the litle box? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 02:34 Message: Logged In: YES user_id=17929 This patch tries to mmap via /dev/zero if neither MAP_ANON nor MAP_ANONYMOUS is defined and handles the case where only MAP_ANONYMOUS is defined. I've added some tests, and found that test_mmap executed mmap(-1, ...), which probably would have crashed the tests running on OS X. Aren't the tests being run before release on all major platforms? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 00:59 Message: Logged In: YES user_id=17929 Well, seems like one would also need some special handling for systems only defining one of MAP_ANON/MAP_ANONYOUS: http://www.winehq.org/hypermail/wine-devel/2004/12/0064.html ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 00:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-16 21:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Sun Feb 5 07:02:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 22:02:42 -0800 Subject: [Patches] [ python-Patches-1408584 ] Corrupt Berkeley DB using Modify bsddb.dbtables Message-ID: Patches item #1408584, was opened at 2006-01-17 14:55 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: jross (j_ross) >Assigned to: Gregory P. Smith (greg) Summary: Corrupt Berkeley DB using Modify bsddb.dbtables Initial Comment: OS: Windows 2000/Windows XP/Debian-based Linux w/2.6.10 Kernel When the Modify function from the dbtables.py module is called on Berkeley DB it corrupts the file showing an error caused by Line 445 of dbtables.py. ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 15:07 Message: Logged In: YES user_id=1429720 Very nice .. yes using a bare exception causes the expected TypeError exception. I tried this in Python 2.4 and without any changes it correctly raises TypeError. I checked the differences between the 2.3 dbtables and 2.4 and there are no significant changes (i.e. the Modify catches the same exceptions) so it's got to be somewhere else. I've uploaded a simple test case that creates a database, does an Insert and then attempts the Modify with a string which corrupts the DB in Python 2.3. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-19 14:35 Message: Logged In: YES user_id=764593 Correct, the values in the dictionaries should be callables (usually a function) which take the old value and return the new. That said, the test case would still be useful, because (1) calling a string should raise a TypeError (2) making a mistake should not corrupt the database. Perhaps the first except clause (which triggers a rollback) needs to be a bare except? I'm guess the same is true of some of the other abort() lines... ---------------------------------------------------------------------- Comment By: jross (j_ross) Date: 2006-01-19 10:11 Message: Logged In: YES user_id=1429720 I'm new to Python so this may be the problem, does the dbtables.Modify function require a function in the mappings. i.e. tdb.Modify('mytable', conditions= {'ID':dbtables.ExactCond('1')}, mappings={'ID':FUNCTION}) where the function returns the new value? (not mappings= {'ID':'newvalue'}) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 22:14 Message: Logged In: YES user_id=33168 Can you create a test case for this? What is the trigger? Just calling the function/method? Do you know if this affects Python 2.4 and HEAD? What version of Berkeley DB? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1408584&group_id=5470 From noreply at sourceforge.net Sun Feb 5 08:21:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Feb 2006 23:21:31 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 15:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-02-05 08:21 Message: Logged In: YES user_id=21627 I looked at the "compatible with DOS" issue again, and I think the story is this: The low-order byte of the external file attributes are the DOS bits (read-only, hidden, system, directory); one can claim compatibility if these bits have the right values. The Unix bits are the higher 16 bits, and can have indepedent values. InfoZIP (on Unix) will use the Unix bits as is-if the creator system is UNIX, VMS, ACORN, ATARI, ATHEOS, BEOS, QDOS or TANDEM. For FAT (0), it will use the Unix bits if they are "consistent" with the DOS bits. In all other cases (including NTFS and MAC), it will use the DOS bits. "consistent" is defined wrt. the U bits: the DOS directory bit must be the same as the u+x bit, and the u+w bit must be the negated read-only bit. If only the DOS bits are used, they are used to synthesize POSIX bits: u,g,o get all the same bits, the w bits are derived from read-only, and the x bit is derived from the subdir bit. As for -X (restore UID/GID): They come from the PK Unix extra field (0x000d), the InfoZip Unix extra field (0x5855) or the InfoZIP Unix2 extra field (0x7855). We currently don't create any of these, so this option in unzip won't have any effect. ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-02-01 12:00 Message: Logged In: YES user_id=315964 I would contend that UNIX file permissions are not compatible with MS-DOS though it is possible that PKZIP 2.04g might read them and convert them to an approximation. I would hope that an unzipping program would ignore any file type code that it did not know how to interpret. The ZIP spec explicitly says the the external file attributes are set to zero in the case where input is from standard input. I infer from that that an unzipper should at least be able to extract the bytes of a file. Rather than argue over fine points of interpretation I think that we should take the pragmatic view that a ZIP archive is most likely to be unzipped on the same type of file system that it was created on. The file system code is indeed more complicated. Setting one type for the archive is limiting. It ought to be set for each member. And yes, it should be file system rather than OS. unzip does honor the file mode. External file attributes must be interpreted according to 'version made by'. It does have options such as '-X restore UID/GID info' but those control how much metadata is unpacked, not override incorrect fields. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-31 21:36 Message: Logged In: YES user_id=21627 I think it is more complicated than that. In version 6.2.2, a value of 19 is assigned to OS/X. There might also be cases when 10 (Windows NTFS) is the right answer; it appears they look at the file system rather than the operating system. HOWEVER, it also says that the value should be 0 if the external file attributes are compatible with DOS and pkzip 2.04g. Perhaps it is a bug in unzip that it doesn't honor the file mode? ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-01-26 17:49 Message: Logged In: YES user_id=315964 The merged patch looks good. One extra comment that I'd made was that if os.name is 'java' then a further query of java.lang.System.getProperty("os.name") might be in order. The string returned from that is 'Linux', 'Windows XP' and 'SunOS' on the platforms I can test. A quick search turned up this page: http://lopica.sourceforge.net/os.html On that basis I'd propose a rule that if the Java os.name starts with 'Windows' or 'OS/2' then use 0; if it starts with 'Mac OS' then 7; else 3. Perhaps someone with 'Mac OS X' could pronounce whether it ought to be 3 (UNIX) or 7 (Macintosh). Comments from Jython experts welcome as well. The spec for the ZIP file format is at PKWARE. http://www.pkware.com/business_and_developers/developer/ popups/appnote.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 11:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Sun Feb 5 15:35:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Feb 2006 06:35:07 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 15:48 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-02-05 15:35 Message: Logged In: YES user_id=580910 Martin, Thank you for investigating this. It seems to me that my original patch should be save then, it sets the creator_system to unix on unix-y systems only. The current version of zipfile sets the higher 16 bits external_attr to the file mode as returned os.stat and doesn't set the lower bits at all (the comment mentions 'unix attributes'). As you already noticed zipfile doesn't set any other attributes, such as user and group, and IMHO that wouldn't be very useful for most usecases anyway. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-05 08:21 Message: Logged In: YES user_id=21627 I looked at the "compatible with DOS" issue again, and I think the story is this: The low-order byte of the external file attributes are the DOS bits (read-only, hidden, system, directory); one can claim compatibility if these bits have the right values. The Unix bits are the higher 16 bits, and can have indepedent values. InfoZIP (on Unix) will use the Unix bits as is-if the creator system is UNIX, VMS, ACORN, ATARI, ATHEOS, BEOS, QDOS or TANDEM. For FAT (0), it will use the Unix bits if they are "consistent" with the DOS bits. In all other cases (including NTFS and MAC), it will use the DOS bits. "consistent" is defined wrt. the U bits: the DOS directory bit must be the same as the u+x bit, and the u+w bit must be the negated read-only bit. If only the DOS bits are used, they are used to synthesize POSIX bits: u,g,o get all the same bits, the w bits are derived from read-only, and the x bit is derived from the subdir bit. As for -X (restore UID/GID): They come from the PK Unix extra field (0x000d), the InfoZip Unix extra field (0x5855) or the InfoZIP Unix2 extra field (0x7855). We currently don't create any of these, so this option in unzip won't have any effect. ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-02-01 12:00 Message: Logged In: YES user_id=315964 I would contend that UNIX file permissions are not compatible with MS-DOS though it is possible that PKZIP 2.04g might read them and convert them to an approximation. I would hope that an unzipping program would ignore any file type code that it did not know how to interpret. The ZIP spec explicitly says the the external file attributes are set to zero in the case where input is from standard input. I infer from that that an unzipper should at least be able to extract the bytes of a file. Rather than argue over fine points of interpretation I think that we should take the pragmatic view that a ZIP archive is most likely to be unzipped on the same type of file system that it was created on. The file system code is indeed more complicated. Setting one type for the archive is limiting. It ought to be set for each member. And yes, it should be file system rather than OS. unzip does honor the file mode. External file attributes must be interpreted according to 'version made by'. It does have options such as '-X restore UID/GID info' but those control how much metadata is unpacked, not override incorrect fields. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-31 21:36 Message: Logged In: YES user_id=21627 I think it is more complicated than that. In version 6.2.2, a value of 19 is assigned to OS/X. There might also be cases when 10 (Windows NTFS) is the right answer; it appears they look at the file system rather than the operating system. HOWEVER, it also says that the value should be 0 if the external file attributes are compatible with DOS and pkzip 2.04g. Perhaps it is a bug in unzip that it doesn't honor the file mode? ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-01-26 17:49 Message: Logged In: YES user_id=315964 The merged patch looks good. One extra comment that I'd made was that if os.name is 'java' then a further query of java.lang.System.getProperty("os.name") might be in order. The string returned from that is 'Linux', 'Windows XP' and 'SunOS' on the platforms I can test. A quick search turned up this page: http://lopica.sourceforge.net/os.html On that basis I'd propose a rule that if the Java os.name starts with 'Windows' or 'OS/2' then use 0; if it starts with 'Mac OS' then 7; else 3. Perhaps someone with 'Mac OS X' could pronounce whether it ought to be 3 (UNIX) or 7 (Macintosh). Comments from Jython experts welcome as well. The spec for the ZIP file format is at PKWARE. http://www.pkware.com/business_and_developers/developer/ popups/appnote.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 11:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Sun Feb 5 16:09:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Feb 2006 07:09:29 -0800 Subject: [Patches] [ python-Patches-1407135 ] anonymous mmap Message-ID: Patches item #1407135, was opened at 2006-01-16 09:44 Message generated for change (Comment added) made by titty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 Please note that this 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: Ralf Schmitt (titty) Assigned to: Neal Norwitz (nnorwitz) Summary: anonymous mmap Initial Comment: make mmap.mmap(-1, size) map anonymous memory on both windows and unix-like systems. If this goes in, I'll also write some documentation. here's some more reasoning: https://sourceforge.net/tracker/? func=detail&atid=105470&aid=1402308&group_id=5470 ---------------------------------------------------------------------- >Comment By: Ralf Schmitt (titty) Date: 2006-02-05 16:09 Message: Logged In: YES user_id=17929 The manpages for open(2) on FreeBSD 4.11, Ubuntu 5.10 and OpenBSD 3.8 all mention '#include ' in their synopsis, so I guess it might be a good idea to include it. I ran Lib/test/test_mmap.py for python trunk on FreeBSD, OpenBSD, Ubuntu and Suse8/amd64 with success. That one comment should now read 'maybe define MAP_ANONYMOUS in terms of MAP_ANON'. However, I didn't test 2.4.3... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 07:01 Message: Logged In: YES user_id=33168 I modified the patch some. Removed include since that didn't seem necessary. Changed the #ifdef slightly. Modified comments. I now understand that anonymous memory was allowed on Unix before (in 2.3 and pre 2.4.2). I backported the non-feature enhancements of this patch (not dup()ing -1). So 2.4.3 should work like 2.4.1 and earlier. It would be great if you can test out 2.5 and 2.4.3 from SVN. Committed revision 42244. Committed revision 42245. (2.4) ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-18 10:16 Message: Logged In: YES user_id=17929 Thanks for the insight. And yes, I forgot to check that little box. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 07:24 Message: Logged In: YES user_id=33168 To answer your question: > Aren't the tests being run before release on all major platforms? It's difficult to answer. I think generally the answer is yes, but it all depends on volunteers. We are currently running tests on every checkin: http://www.python.org/dev/buildbot/ for both HEAD and 2.4 branch. BuildBot is a relatively recent addition though. On OS X 10.3, we aren't having a problem with mmap(). Various developers I know use OS X, not sure which versions of OS X though. -- General comments about the patch: For any solution, we should strive to make it available if possible (with reason) on all platforms. We should attempt to have all versions of Python behave similarly. (I'm not trying to imply you aren't working in this direction, it seems like you are.) I only notice one patch attached. Have you been deleting the others or did you forget to check the litle box? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 11:34 Message: Logged In: YES user_id=17929 This patch tries to mmap via /dev/zero if neither MAP_ANON nor MAP_ANONYMOUS is defined and handles the case where only MAP_ANONYMOUS is defined. I've added some tests, and found that test_mmap executed mmap(-1, ...), which probably would have crashed the tests running on OS X. Aren't the tests being run before release on all major platforms? ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:59 Message: Logged In: YES user_id=17929 Well, seems like one would also need some special handling for systems only defining one of MAP_ANON/MAP_ANONYOUS: http://www.winehq.org/hypermail/wine-devel/2004/12/0064.html ---------------------------------------------------------------------- Comment By: Ralf Schmitt (titty) Date: 2006-01-17 09:48 Message: Logged In: YES user_id=17929 quoting ubuntu's mmap man page: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset arguments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. MAP_ANON Alias for MAP_ANONYMOUS. Deprecated. --- On a glibc 2.1 system (once installed with a 2.2 kernel, now running a 2.4 one) the manpage doesn't even mention MAP_ANON(YMOUS). The patch in it's current form will just fail on system's not defining MAP_ANON (i.e. mmap will fail and an exception will be raised). However, according to Stevens 'Advanced Programming in the Unix Environment', chapter 14.9, there are two ways to mmap anonymous memory. The first one works by using MAP_ANON (4.3+BSD), and the second one works by opening /dev/zero and passing that as a filedescriptor to mmap (SVR4). So, I guess all BSD's and newer Linux Systems would work with this version. Anyway I can send another patch handling that case if you like? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-17 06:22 Message: Logged In: YES user_id=33168 In addition to docs, tests will also be necessary before committing. What if fd == -1 and MAP_ANON is not defined? It seems the state could be inconsistent. Shouldn't an exception be raised in this case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407135&group_id=5470 From noreply at sourceforge.net Sun Feb 5 18:14:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Feb 2006 09:14:16 -0800 Subject: [Patches] [ python-Patches-1412872 ] zipfile: use correct system type on unixy systems Message-ID: Patches item #1412872, was opened at 2006-01-23 15:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 Please note that this 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: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile: use correct system type on unixy systems Initial Comment: This patch updates the contructor of zipfile.ZipInfo to initialize the create_system attribute to 3 instead of 0 on systems that are not Windows. Without this patch the unzip command won't honour the file mode that is stored in the zip file. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-02-05 18:14 Message: Logged In: YES user_id=21627 I agree, and have committed the original patch as r42250. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-02-05 15:35 Message: Logged In: YES user_id=580910 Martin, Thank you for investigating this. It seems to me that my original patch should be save then, it sets the creator_system to unix on unix-y systems only. The current version of zipfile sets the higher 16 bits external_attr to the file mode as returned os.stat and doesn't set the lower bits at all (the comment mentions 'unix attributes'). As you already noticed zipfile doesn't set any other attributes, such as user and group, and IMHO that wouldn't be very useful for most usecases anyway. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-05 08:21 Message: Logged In: YES user_id=21627 I looked at the "compatible with DOS" issue again, and I think the story is this: The low-order byte of the external file attributes are the DOS bits (read-only, hidden, system, directory); one can claim compatibility if these bits have the right values. The Unix bits are the higher 16 bits, and can have indepedent values. InfoZIP (on Unix) will use the Unix bits as is-if the creator system is UNIX, VMS, ACORN, ATARI, ATHEOS, BEOS, QDOS or TANDEM. For FAT (0), it will use the Unix bits if they are "consistent" with the DOS bits. In all other cases (including NTFS and MAC), it will use the DOS bits. "consistent" is defined wrt. the U bits: the DOS directory bit must be the same as the u+x bit, and the u+w bit must be the negated read-only bit. If only the DOS bits are used, they are used to synthesize POSIX bits: u,g,o get all the same bits, the w bits are derived from read-only, and the x bit is derived from the subdir bit. As for -X (restore UID/GID): They come from the PK Unix extra field (0x000d), the InfoZip Unix extra field (0x5855) or the InfoZIP Unix2 extra field (0x7855). We currently don't create any of these, so this option in unzip won't have any effect. ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-02-01 12:00 Message: Logged In: YES user_id=315964 I would contend that UNIX file permissions are not compatible with MS-DOS though it is possible that PKZIP 2.04g might read them and convert them to an approximation. I would hope that an unzipping program would ignore any file type code that it did not know how to interpret. The ZIP spec explicitly says the the external file attributes are set to zero in the case where input is from standard input. I infer from that that an unzipper should at least be able to extract the bytes of a file. Rather than argue over fine points of interpretation I think that we should take the pragmatic view that a ZIP archive is most likely to be unzipped on the same type of file system that it was created on. The file system code is indeed more complicated. Setting one type for the archive is limiting. It ought to be set for each member. And yes, it should be file system rather than OS. unzip does honor the file mode. External file attributes must be interpreted according to 'version made by'. It does have options such as '-X restore UID/GID info' but those control how much metadata is unpacked, not override incorrect fields. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-01-31 21:36 Message: Logged In: YES user_id=21627 I think it is more complicated than that. In version 6.2.2, a value of 19 is assigned to OS/X. There might also be cases when 10 (Windows NTFS) is the right answer; it appears they look at the file system rather than the operating system. HOWEVER, it also says that the value should be 0 if the external file attributes are compatible with DOS and pkzip 2.04g. Perhaps it is a bug in unzip that it doesn't honor the file mode? ---------------------------------------------------------------------- Comment By: Pete Forman (pete_forman) Date: 2006-01-26 17:49 Message: Logged In: YES user_id=315964 The merged patch looks good. One extra comment that I'd made was that if os.name is 'java' then a further query of java.lang.System.getProperty("os.name") might be in order. The string returned from that is 'Linux', 'Windows XP' and 'SunOS' on the platforms I can test. A quick search turned up this page: http://lopica.sourceforge.net/os.html On that basis I'd propose a rule that if the Java os.name starts with 'Windows' or 'OS/2' then use 0; if it starts with 'Mac OS' then 7; else 3. Perhaps someone with 'Mac OS X' could pronounce whether it ought to be 3 (UNIX) or 7 (Macintosh). Comments from Jython experts welcome as well. The spec for the ZIP file format is at PKWARE. http://www.pkware.com/business_and_developers/developer/ popups/appnote.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-01-26 11:34 Message: Logged In: YES user_id=580910 I've updated the patch based on a simular patch by Pete Forman (UID: pete_forman). This version contains a lookup-table of create_systems based on the os.name and also supports some other non-windows systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1412872&group_id=5470 From noreply at sourceforge.net Sun Feb 5 21:39:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Feb 2006 12:39:35 -0800 Subject: [Patches] [ python-Patches-1422385 ] Changes to nis module to support multiple NIS domains Message-ID: Patches item #1422385, was opened at 2006-02-02 11:26 Message generated for change (Comment added) made by csuwi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 Please note that this 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: Accepted Priority: 5 Submitted By: Ben Bell (csuwi) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to nis module to support multiple NIS domains Initial Comment: The nis module currently has no way to access nis domains other than the default NIS domain. This is fairly easy to achieve via the C API and so I've patched it. Summary of changes: I've added a new get_default_domain() function and exposed it to python. I've added an optional "domain" keyword arg to the cat, maps and match arguments but defaulted it to the default domain to ensure backwards compatibility. ---------------------------------------------------------------------- >Comment By: Ben Bell (csuwi) Date: 2006-02-05 20:39 Message: Logged In: YES user_id=145982 Diff to test added. Thanks for the tips on future changes. Noted. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-04 22:45 Message: Logged In: YES user_id=33168 Ben, could you also update Lib/test/test_nis.py to test the new code? ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 19:14 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as revision 42235. In the future, please remember the following details: - use PyDoc_STRVAR for documentation variables - add changes to the tex documentation as well ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-04 15:32 Message: Logged In: YES user_id=145982 Sorry, uploaded this time ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-02-04 11:34 Message: Logged In: YES user_id=21627 Can you please attach the new patch to the report? ---------------------------------------------------------------------- Comment By: Ben Bell (csuwi) Date: 2006-02-02 12:02 Message: Logged In: YES user_id=145982 The previous patch was a little lazy. I've now taken the opportunity to add module doc and fix the two compile time warnings as well. New diff attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1422385&group_id=5470 From noreply at sourceforge.net Tue Feb 7 08:18:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Feb 2006 23:18:30 -0800 Subject: [Patches] [ python-Patches-970288 ] Fix for #876637 - Random stack corruption from socketmodule Message-ID: Patches item #970288, was opened at 2004-06-10 04:13 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470 Please note that this 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: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #876637 - Random stack corruption from socketmodule Initial Comment: Here's a patch to convert socketmodule to use poll() for the timeout handling. ifdefs and includes have been copied from selectmodule, so I believe they should be correct for all platforms. Compiled and tested on Linux (RH73). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-06 23:18 Message: Logged In: YES user_id=33168 A fix for the bug (sd over FD_SETSIZE) has been checked in. Note select is called in Modules/_ssl.c too. ---------------------------------------------------------------------- Comment By: Troels Walsted Hansen (troels) Date: 2004-08-26 00:07 Message: Logged In: YES user_id=32863 You're right, however I think that it is a very minor problem compared to the current situation. All major UNIX platforms support poll(2) in my experience. The only important Python platform without poll is Windows, and it doesn't have the FD_SETSIZE problem. Thus I think the patch should be applied as it stands, but the original bug ticket can be left open for another enterprising individual to make the changes you suggest. I'm afraid that work commitments prevent me from being that individual for the foreseeable future... ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-08-22 09:30 Message: Logged In: YES user_id=21627 While the patch is good as it stands, it is also incomplete: If poll(2) is not available, it might still overrun the FD_SETSIZE. I think there should be another return value from internal_select (-1), indicating an internal error. A Python RuntimeError should be set in this case. Callers should check for -1, and return immediately. Are you willing to extend the patch in that direction? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=970288&group_id=5470 From noreply at sourceforge.net Tue Feb 7 22:34:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Feb 2006 13:34:59 -0800 Subject: [Patches] [ python-Patches-1426648 ] urllib proxy_bypass broken Message-ID: Patches item #1426648, was opened at 2006-02-07 14: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=1426648&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: urllib proxy_bypass broken Initial Comment: If a port number is included in the url, the code in proxy_bypass fails to determine the IP address of the host which means that proxy bypass definitions of x.x.x.* will be ignored. In addition, the fully qualified domain name is not acquired so if the fully qualified domain name is not specified in the URL the proxy bypass will be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1426648&group_id=5470 From noreply at sourceforge.net Thu Feb 9 16:56:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Feb 2006 07:56:23 -0800 Subject: [Patches] [ python-Patches-1101097 ] Feed style codec API Message-ID: Patches item #1101097, was opened at 2005-01-12 19:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 Please note that this 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: M.-A. Lemburg (lemburg) Summary: Feed style codec API Initial Comment: The attached patch implements a feed style codec API by adding feed methods to StreamReader and StreamWriter (see SF patch #998993 for a history of this issue). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-02-09 16:56 Message: Logged In: YES user_id=89016 Looking at PEP 342 I think the natural name for this method would be send(). It does exactly what send() does for generators: in sends data into the codec, which processes it, returns a result and keeps state for the next call. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-12 16:41 Message: Logged In: YES user_id=89016 Basically what I want to have is a decoupling of the stateful encoding/decoding from the stream API. An example: Suppose I have a generator: def foo(): yield u"Hello" yield u"World" I want to wrap this generator into another generator that does a stateful encoding of the strings from the first generator: def encode(it, encoding, errors): writer = codecs.getwriter(encoding)(None, errors) for data in it: yield writer.feed(data) for x in encode(foo(), "utf-16", "strict"): print repr(x) '\xff\xfeH\x00e\x00l\x00l\x00o\x00' 'W\x00o\x00r\x00l\x00d\x00' The writer itself shouldn't write anything to the stream (in fact, there is no stream), it should just encode what it gets fed and spit out the result. The reason why StreamWriter.feed() is implemented the way it is, is that currently there are no Python encodings where encode(string)[1] != len(string). If we want to handle that case the StreamWriter would have to grow a charbuffer. Should I add that to the patch? For decoding I want the same functionality: def blocks(name, size=8192): f = open(name, "rb") while True: data = f.read(size) if data: yield data else: break def decode(it, encoding, errors): reader = codecs.getreader(encoding)(None, errors) for data in it: yield reader.feed(data) decode(blocks("foo.xml")) Again, here the StreamReader doesn't read for a stream, it just decodes what it gets fed and spits it back out. I'm not attached to the name "feed". Of course the natural choice for the method names would be "encode" and "decode", but those are already taken. Would "handle" or "convert" be better names? I don't know what the "this" refers to in "This is not what your versions implement". If "this" refers to "The idea is to allow incremental processing", this is exactly what the patch tries to achieve: Incremental processing without tying this processing to a stream API. If "this" refers to "feed style APIs usually take data and store it in the object's state" that's true, but that's not the purpose of the patch, so maybe the name *is* misleading. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-12 15:20 Message: Logged In: YES user_id=38388 I don't like the name of the methods, since feed style APIs usually take data and store in the object's state whereas the method you are suggesting is merely an encode method that takes the current state into account. The idea is to allow incremental processing. This is not what your versions implement. The StreamWriter would have to grow buffering for this. The .feed() method on the StreamReader would have to be adjusted to store the input in the .charbuffer only and not return anything. If you just want to make the code easier to follow, I'd suggest you use private methods, e.g. ._stateful_encode() and ._stateful_decode() - which is what these method do implement. Please also explain "If only the \method{feed()} method is used, \var{stream} will be ignored and can be \constant{None}.". I don't see this being true - .write() will still require a .stream object. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-11 22:48 Message: Logged In: YES user_id=89016 The second version of the patch is updated for the current svn head and includes patches to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 From noreply at sourceforge.net Thu Feb 9 18:58:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Feb 2006 09:58:43 -0800 Subject: [Patches] [ python-Patches-1101097 ] Feed style codec API Message-ID: Patches item #1101097, was opened at 2005-01-12 19:14 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 Please note that this 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: M.-A. Lemburg (lemburg) Summary: Feed style codec API Initial Comment: The attached patch implements a feed style codec API by adding feed methods to StreamReader and StreamWriter (see SF patch #998993 for a history of this issue). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-02-09 18:58 Message: Logged In: YES user_id=38388 I can see your point in wanting a way to use the stateful encoding/decoding, but still don't understand why you have to sidestep the stream API for doing this. Wouldn't using a StringIO buffer as stream be the more natural choice for the writer and for the reader (StringIO supports Unicode as well). You can then use the standard .write() API to "send" in the data and the .getvalue() method on the StringIO buffer to fetch the results. For the reader, you'd write to the StringIO buffer and then fetch the results using the standard .read() API. This is how you'd normally use a file or stream IO based API in a string context and it doesn't require adding methods to the StreamReader/Writer API. I'm not opposed to adding new methods, but you see, the whole point of StreamReader/Writer is to read from and write to streams. If you just want a stateful encoder/decoder it would be better to create a separate implementation for that, say StatefulEncoder/StatefulDecoder (which could then be used by the StreamReader/Writer). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-02-09 16:56 Message: Logged In: YES user_id=89016 Looking at PEP 342 I think the natural name for this method would be send(). It does exactly what send() does for generators: in sends data into the codec, which processes it, returns a result and keeps state for the next call. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-12 16:41 Message: Logged In: YES user_id=89016 Basically what I want to have is a decoupling of the stateful encoding/decoding from the stream API. An example: Suppose I have a generator: def foo(): yield u"Hello" yield u"World" I want to wrap this generator into another generator that does a stateful encoding of the strings from the first generator: def encode(it, encoding, errors): writer = codecs.getwriter(encoding)(None, errors) for data in it: yield writer.feed(data) for x in encode(foo(), "utf-16", "strict"): print repr(x) '\xff\xfeH\x00e\x00l\x00l\x00o\x00' 'W\x00o\x00r\x00l\x00d\x00' The writer itself shouldn't write anything to the stream (in fact, there is no stream), it should just encode what it gets fed and spit out the result. The reason why StreamWriter.feed() is implemented the way it is, is that currently there are no Python encodings where encode(string)[1] != len(string). If we want to handle that case the StreamWriter would have to grow a charbuffer. Should I add that to the patch? For decoding I want the same functionality: def blocks(name, size=8192): f = open(name, "rb") while True: data = f.read(size) if data: yield data else: break def decode(it, encoding, errors): reader = codecs.getreader(encoding)(None, errors) for data in it: yield reader.feed(data) decode(blocks("foo.xml")) Again, here the StreamReader doesn't read for a stream, it just decodes what it gets fed and spits it back out. I'm not attached to the name "feed". Of course the natural choice for the method names would be "encode" and "decode", but those are already taken. Would "handle" or "convert" be better names? I don't know what the "this" refers to in "This is not what your versions implement". If "this" refers to "The idea is to allow incremental processing", this is exactly what the patch tries to achieve: Incremental processing without tying this processing to a stream API. If "this" refers to "feed style APIs usually take data and store it in the object's state" that's true, but that's not the purpose of the patch, so maybe the name *is* misleading. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-01-12 15:20 Message: Logged In: YES user_id=38388 I don't like the name of the methods, since feed style APIs usually take data and store in the object's state whereas the method you are suggesting is merely an encode method that takes the current state into account. The idea is to allow incremental processing. This is not what your versions implement. The StreamWriter would have to grow buffering for this. The .feed() method on the StreamReader would have to be adjusted to store the input in the .charbuffer only and not return anything. If you just want to make the code easier to follow, I'd suggest you use private methods, e.g. ._stateful_encode() and ._stateful_decode() - which is what these method do implement. Please also explain "If only the \method{feed()} method is used, \var{stream} will be ignored and can be \constant{None}.". I don't see this being true - .write() will still require a .stream object. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-01-11 22:48 Message: Logged In: YES user_id=89016 The second version of the patch is updated for the current svn head and includes patches to the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1101097&group_id=5470 From noreply at sourceforge.net Fri Feb 10 02:04:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Feb 2006 17:04:08 -0800 Subject: [Patches] [ python-Patches-1428778 ] Implementation of PEP 357 Message-ID: Patches item #1428778, was opened at 2006-02-09 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=1428778&group_id=5470 Please note that this 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: Travis Oliphant (teoliphant) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of PEP 357 Initial Comment: See PEP 357 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428778&group_id=5470 From noreply at sourceforge.net Fri Feb 10 02:05:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Feb 2006 17:05:00 -0800 Subject: [Patches] [ python-Patches-1428778 ] Implementation of PEP 357 Message-ID: Patches item #1428778, was opened at 2006-02-09 18:04 Message generated for change (Settings changed) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428778&group_id=5470 Please note that this 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: Travis Oliphant (teoliphant) >Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 357 Initial Comment: See PEP 357 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428778&group_id=5470 From noreply at sourceforge.net Fri Feb 10 20:40:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Feb 2006 11:40:59 -0800 Subject: [Patches] [ python-Patches-1428494 ] Prefer linking against ncursesw over ncurses library Message-ID: Patches item #1428494, was opened at 2006-02-09 19:03 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428494&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Ian Ward (ian_ward) >Assigned to: Martin v. L??wis (loewis) Summary: Prefer linking against ncursesw over ncurses library Initial Comment: The curses module cannot display characters in the UTF-8 encoding unless _curses it is linked agains ncursesw. This patch checks for and uses the ncursesw version of the ncurses library before looking for other versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428494&group_id=5470 From noreply at sourceforge.net Fri Feb 10 20:51:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Feb 2006 11:51:18 -0800 Subject: [Patches] [ python-Patches-1428655 ] Use snprintf for static buffers Message-ID: Patches item #1428655, was opened at 2006-02-09 22:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428655&group_id=5470 Please note that this 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: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: Use snprintf for static buffers Initial Comment: Hi, there are some uses of sprintf in the Python C code. Unfortunately sprintf is known to cause buffer overruns. To prevent this I have written a patch that replaces sprintf with snprintf. To be on the safe side (and since I don't know much of the C code internals) I only changed static buffers, where the sizeof() operator is known to work. The patch is against SVN 42293, and tested on a i386 Debian Linux system. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-02-10 20:51 Message: Logged In: YES user_id=21627 The patch has several problems: 1. It is unnecessary. The print calls actually *cannot* cause buffer overruns, because in all cases, the buffers are large enough. 2. The insertion of a trailing null-byte is unnecessary: snprintf will already add that byte, even if it runs out of space. The first argument could be discarded, since using snprintf can be considered as improving maintainability; point 2 actually decreases maintainability. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1428655&group_id=5470 From noreply at sourceforge.net Sat Feb 11 04:34:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Feb 2006 19:34:09 -0800 Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import __main__ pdb failure) Message-ID: Patches item #1429539, was opened at 2006-02-10 19: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=1429539&group_id=5470 Please note that this 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: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb: fix for 1326406 (import __main__ pdb failure) Initial Comment: The patch allows pdb to debug program which import from __main__ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470 From noreply at sourceforge.net Sat Feb 11 09:43:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Feb 2006 00:43:30 -0800 Subject: [Patches] [ python-Patches-1429591 ] Implement PEP 357 for real Message-ID: Patches item #1429591, was opened at 2006-02-11 01:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429591&group_id=5470 Please note that this 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: Travis Oliphant (teoliphant) Assigned to: Nobody/Anonymous (nobody) Summary: Implement PEP 357 for real Initial Comment: Contains latest PEP 357 implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429591&group_id=5470 From noreply at sourceforge.net Sat Feb 11 09:44:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Feb 2006 00:44:29 -0800 Subject: [Patches] [ python-Patches-1429591 ] Implement PEP 357 for real Message-ID: Patches item #1429591, was opened at 2006-02-11 01:43 Message generated for change (Settings changed) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429591&group_id=5470 Please note that this 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: Travis Oliphant (teoliphant) >Assigned to: Guido van Rossum (gvanrossum) Summary: Implement PEP 357 for real Initial Comment: Contains latest PEP 357 implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429591&group_id=5470 From noreply at sourceforge.net Sat Feb 11 09:51:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Feb 2006 00:51:23 -0800 Subject: [Patches] [ python-Patches-1043356 ] Enhancing '-m' to support packages (PEP 338) Message-ID: Patches item #1043356, was opened at 2004-10-09 07:44 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1043356&group_id=5470 Please note that this 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: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhancing '-m' to support packages (PEP 338) Initial Comment: Thomas Heller posted "python -m pychecker.checker