From ojlj at improve.fr Wed Nov 1 16:25:26 2006 From: ojlj at improve.fr (Morgan Blackburn) Date: Wed, 1 Nov 2006 16:25:26 +0100 Subject: [Patches] firebrand Message-ID: <4548BC66.1000307@cavandreu.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061101/be8d822f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: occupy.gif Type: image/gif Size: 8965 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061101/be8d822f/attachment.gif From noreply at sourceforge.net Wed Nov 1 16:27:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 07:27:47 -0800 Subject: [Patches] [ python-Patches-1587674 ] Patch for #1586414 to avoid fragmentation on Windows Message-ID: Patches item #1587674, was opened at 2006-10-31 06:05 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1586414 to avoid fragmentation on Windows Initial Comment: Add a call to file.truncate() to inform Windows of the size of the target file in makefile(). This helps guide cluster allocation in NTFS to avoid fragmentation. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-01 16:27 Message: Logged In: YES user_id=642936 Is this merely an NTFS problem or is it the same with FAT fs? How do you detect file fragmentation? Doesn't this problem apply to all other modules or scripts that write to file objects as well? Shouldn't a decent filesystem be able to handle growing files in a correct manner? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 From rha at sts-communications.com Wed Nov 1 18:21:10 2006 From: rha at sts-communications.com (Lewie Godfrey) Date: Wed, 1 Nov 2006 18:21:10 +0100 Subject: [Patches] abysmal artificially Message-ID: <4548D786.9080309@commonact.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061101/9633affa/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: punk.gif Type: image/gif Size: 9317 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061101/9633affa/attachment-0001.gif From noreply at sourceforge.net Thu Nov 2 02:40:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 17:40:14 -0800 Subject: [Patches] [ python-Patches-1589013 ] Typo in Mac installer image name Message-ID: Patches item #1589013, was opened at 2006-11-01 23:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589013&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Jack Jansen (jackjansen) Summary: Typo in Mac installer image name Initial Comment: When installing Python on a Mac, the image is mounted with a wrong name: "Univeral" MacPython. $ mount | grep Py /dev/disk1s2 on /Volumes/Univeral MacPython 2.4.4 (...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589013&group_id=5470 From noreply at sourceforge.net Thu Nov 2 02:42:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 17:42:05 -0800 Subject: [Patches] [ python-Patches-1589014 ] Typo in Mac image name Message-ID: Patches item #1589014, was opened at 2006-11-01 23:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Jack Jansen (jackjansen) Summary: Typo in Mac image name Initial Comment: When installing Python on a Mac, the image is mounted with a wrong name: "Univeral" MacPython. $ mount | grep Py /dev/disk1s2 on /Volumes/Univeral MacPython 2.4.4 (...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589014&group_id=5470 From noreply at sourceforge.net Thu Nov 2 02:43:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 17:43:14 -0800 Subject: [Patches] [ python-Patches-1589014 ] Typo in Mac image name Message-ID: Patches item #1589014, was opened at 2006-11-01 23:42 Message generated for change (Comment added) made by virtualspirit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Jack Jansen (jackjansen) Summary: Typo in Mac image name Initial Comment: When installing Python on a Mac, the image is mounted with a wrong name: "Univeral" MacPython. $ mount | grep Py /dev/disk1s2 on /Volumes/Univeral MacPython 2.4.4 (...) ---------------------------------------------------------------------- >Comment By: Humberto Di?genes (virtualspirit) Date: 2006-11-01 23:43 Message: Logged In: YES user_id=736405 Sorry for the double post. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589014&group_id=5470 From iri at accountingbycomputer.co.uk Thu Nov 2 06:35:32 2006 From: iri at accountingbycomputer.co.uk (Israel Elkins) Date: Wed, 1 Nov 2006 23:35:32 -0600 Subject: [Patches] vacancy Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061101/eff97ba3/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: grumpy.gif Type: image/gif Size: 8264 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061101/eff97ba3/attachment.gif From noreply at sourceforge.net Thu Nov 2 06:44:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 21:44:49 -0800 Subject: [Patches] [ python-Patches-1589070 ] MacPython Build Installer - Typos and Style corrections Message-ID: Patches item #1589070, was opened at 2006-11-02 03:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Jack Jansen (jackjansen) Summary: MacPython Build Installer - Typos and Style corrections Initial Comment: * Corrected many typos (such as "IDLE is an IDLE" instead of "IDLE is an IDE"); * Simplified SRCDIR guessing; * PEP8 style; Includes patch #1589013 ("Univeral" MacPython). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 From noreply at sourceforge.net Thu Nov 2 06:47:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 21:47:01 -0800 Subject: [Patches] [ python-Patches-1589013 ] Typo in Mac installer image name Message-ID: Patches item #1589013, was opened at 2006-11-01 23:40 Message generated for change (Comment added) made by virtualspirit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589013&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Jack Jansen (jackjansen) Summary: Typo in Mac installer image name Initial Comment: When installing Python on a Mac, the image is mounted with a wrong name: "Univeral" MacPython. $ mount | grep Py /dev/disk1s2 on /Volumes/Univeral MacPython 2.4.4 (...) ---------------------------------------------------------------------- >Comment By: Humberto Di?genes (virtualspirit) Date: 2006-11-02 03:47 Message: Logged In: YES user_id=736405 #1589070 contains an expanded version of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589013&group_id=5470 From noreply at sourceforge.net Thu Nov 2 13:51:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 04:51:59 -0800 Subject: [Patches] [ python-Patches-1589070 ] MacPython Build Installer - Typos and Style corrections Message-ID: Patches item #1589070, was opened at 2006-11-02 06:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython Build Installer - Typos and Style corrections Initial Comment: * Corrected many typos (such as "IDLE is an IDLE" instead of "IDLE is an IDE"); * Simplified SRCDIR guessing; * PEP8 style; Includes patch #1589013 ("Univeral" MacPython). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2006-11-02 13:51 Message: Logged In: YES user_id=45365 Ronald, aside from a number of typo fixes (it took me 5 minutes to see that there's an "s" missing in "Univeral MacPython" :-) there's also some changes in the logic; those probably need some eyeballing over (the changes to SRCDIR look a bit suspect). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 From noreply at sourceforge.net Thu Nov 2 14:35:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 05:35:30 -0800 Subject: [Patches] [ python-Patches-1589266 ] bdist_sunpkg distutils command Message-ID: Patches item #1589266, was opened at 2006-11-02 14:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Holger (jholg) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_sunpkg distutils command Initial Comment: Hi, find attached a bdist_sunpkg distutils command class that implements creating a sun solaris package. This has been based on the python2.3 distutils but should work with newer ones, too. Note that a small patch to file_util is needed that adds the verbose/dry_run capabilities to the write_file function. At the moment, fancy things like dependency scripts and stuff are not supported. Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 From noreply at sourceforge.net Thu Nov 2 14:38:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 05:38:47 -0800 Subject: [Patches] [ python-Patches-1589266 ] bdist_sunpkg distutils command Message-ID: Patches item #1589266, was opened at 2006-11-02 14:35 Message generated for change (Comment added) made by jholg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Holger (jholg) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_sunpkg distutils command Initial Comment: Hi, find attached a bdist_sunpkg distutils command class that implements creating a sun solaris package. This has been based on the python2.3 distutils but should work with newer ones, too. Note that a small patch to file_util is needed that adds the verbose/dry_run capabilities to the write_file function. At the moment, fancy things like dependency scripts and stuff are not supported. Holger ---------------------------------------------------------------------- >Comment By: Holger (jholg) Date: 2006-11-02 14:38 Message: Logged In: YES user_id=1315684 (uploaded file_util patch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 From noreply at sourceforge.net Thu Nov 2 21:03:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 12:03:30 -0800 Subject: [Patches] [ python-Patches-1557890 ] missing imports ctypes in documentation examples Message-ID: Patches item #1557890, was opened at 2006-09-13 14:54 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Thomas Heller (theller) Summary: missing imports ctypes in documentation examples Initial Comment: The attached patch fixes a couple of missing imports in ctypes documentation examples. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-02 21:03 Message: Logged In: YES user_id=11105 Unfortuately ;-), dvarrazzo is right. WinError is a symbol exported by ctypes. I'll update the docs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 00:15 Message: Logged In: YES user_id=33168 Thanks for the patch. I think WinError is meant to be a user defined error. There isn't one in ctypes that I saw. So I left that part of the patch out. Instead of adding an import, I used UINT which was already imported and conformed to the prototype given above. Committed revision 52515. (2.5) Committed revision 52514. (2.6) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 From noreply at sourceforge.net Thu Nov 2 21:28:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 12:28:53 -0800 Subject: [Patches] [ python-Patches-1557890 ] missing imports ctypes in documentation examples Message-ID: Patches item #1557890, was opened at 2006-09-13 14:54 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Daniele Varrazzo (dvarrazzo) Assigned to: Thomas Heller (theller) Summary: missing imports ctypes in documentation examples Initial Comment: The attached patch fixes a couple of missing imports in ctypes documentation examples. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-02 21:28 Message: Logged In: YES user_id=11105 Fixed in svn rev 52592 (trunk) and rev 52593 (release25-maint). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-02 21:03 Message: Logged In: YES user_id=11105 Unfortuately ;-), dvarrazzo is right. WinError is a symbol exported by ctypes. I'll update the docs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 00:15 Message: Logged In: YES user_id=33168 Thanks for the patch. I think WinError is meant to be a user defined error. There isn't one in ctypes that I saw. So I left that part of the patch out. Instead of adding an import, I used UINT which was already imported and conformed to the prototype given above. Committed revision 52515. (2.5) Committed revision 52514. (2.6) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1557890&group_id=5470 From noreply at sourceforge.net Thu Nov 2 21:41:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 12:41:37 -0800 Subject: [Patches] [ python-Patches-1559219 ] Practical ctypes example Message-ID: Patches item #1559219, was opened at 2006-09-15 13:01 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: leppton (leppton) Assigned to: Thomas Heller (theller) Summary: Practical ctypes example Initial Comment: Ctypes module documentation can be little hard to grasp, so I wrote a practical example that reads all function names from dll export directory. It has structures, pointer arithmetic, and function prototype with default parameters. Maybe it fits somewhere in documentation... ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-02 21:41 Message: Logged In: YES user_id=11105 I guess that a ~300 line module is too large to add to the documentation. OTOH, this module implements very useful functionality. If you give me the permission to distribute this module under the MIT license, I would like to add it to a 'ctypeslib' supplemental package (which will also contain other useful stuff). Oh, and the same functionality for ELF-based platforms would be very nice ;-). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 From noreply at sourceforge.net Fri Nov 3 01:20:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 16:20:18 -0800 Subject: [Patches] [ python-Patches-1559219 ] Practical ctypes example Message-ID: Patches item #1559219, was opened at 2006-09-15 11:01 Message generated for change (Comment added) made by leppton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: leppton (leppton) Assigned to: Thomas Heller (theller) Summary: Practical ctypes example Initial Comment: Ctypes module documentation can be little hard to grasp, so I wrote a practical example that reads all function names from dll export directory. It has structures, pointer arithmetic, and function prototype with default parameters. Maybe it fits somewhere in documentation... ---------------------------------------------------------------------- >Comment By: leppton (leppton) Date: 2006-11-03 00:20 Message: Logged In: YES user_id=1598785 Permission granted for MIT license. Can't help with ELFs, I'm a windows guy :/ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-02 20:41 Message: Logged In: YES user_id=11105 I guess that a ~300 line module is too large to add to the documentation. OTOH, this module implements very useful functionality. If you give me the permission to distribute this module under the MIT license, I would like to add it to a 'ctypeslib' supplemental package (which will also contain other useful stuff). Oh, and the same functionality for ELF-based platforms would be very nice ;-). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 From noreply at sourceforge.net Sat Nov 4 01:15:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 16:15:00 -0800 Subject: [Patches] [ python-Patches-1589266 ] bdist_sunpkg distutils command Message-ID: Patches item #1589266, was opened at 2006-11-02 14:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Holger (jholg) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_sunpkg distutils command Initial Comment: Hi, find attached a bdist_sunpkg distutils command class that implements creating a sun solaris package. This has been based on the python2.3 distutils but should work with newer ones, too. Note that a small patch to file_util is needed that adds the verbose/dry_run capabilities to the write_file function. At the moment, fancy things like dependency scripts and stuff are not supported. Holger ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 01:15 Message: Logged In: YES user_id=21627 Are you willing to fill out the contribution form, at http://www.python.org/psf/contrib/ ---------------------------------------------------------------------- Comment By: Holger (jholg) Date: 2006-11-02 14:38 Message: Logged In: YES user_id=1315684 (uploaded file_util patch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 From noreply at sourceforge.net Sat Nov 4 07:30:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 22:30:59 -0800 Subject: [Patches] [ python-Patches-1590352 ] The "lazy strings" patch Message-ID: Patches item #1590352, was opened at 2006-11-04 06:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: The "lazy strings" patch Initial Comment: This patch consists of three changes to CPython: * changing PyStringObject.ob_sval, * "lazy concatenations", and * "lazy slices". None of these changes adds new functionality to CPython; they are all speed or memory optimizations. In detail: PyStringObject.ob_sval was changed from a char[] array to a char *. This is not in and of itself particularly desirable. It was necessary in order to implement the other two changes. "lazy concatenations" change string concatenation ("a" + "b") so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string concatenation in CPython is now more than 150% faster on average (as reported by pystone 2.0), and is approximately as fast as the standard string concatenation idiom ("".join([a + b + c])). "lazy slices" changes string slicing ("abc"[1], "a".strip()) so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string slicing in CPython is now more than 60% faster on average (as reported by pystone 2.0). When considering this patch, please keep in mind that the "lazy" changes are distinct, and could be incorporated independently. In particular I'm guessing that "lazy concatenations" have a lot higher chance of being accepted than "lazy slices". These changes were implemented almost entirely in Include/stringobject.h and Objects/stringobject.c. With this patch applied, trunk builds and passes all expected tests on Win32 and Linux. For a more thorough discussion of this patch, please see the attached text file(s). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 From noreply at sourceforge.net Sat Nov 4 19:15:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 10:15:00 -0800 Subject: [Patches] [ python-Patches-1060577 ] bdist_rpm not able to compile multiple rpm packages Message-ID: Patches item #1060577, was opened at 2004-11-04 23:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1060577&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm not able to compile multiple rpm packages Initial Comment: bdist_rpm tries to deal with debuginfo packages by naming them in the source. Just as debuginfo packages are artifacts of a buildystem, one can modify the buildsystem to create various other rpms even though the spec file only creates one. The attached patch tries to approach the solution in a more general way, by looking at the spec file and extracting the names of rpms that are going to be generated. This patch has been posted at some point on the distutils-sig mailing list: http://mail.python.org/pipermail/distutils-sig/2004-June/003953.html I assumed it already made it in, apparently not. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 19:15 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52619 and r52620 ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2006-06-22 18:34 Message: Logged In: YES user_id=205865 Updated patch for python 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1060577&group_id=5470 From KKSKAREBEAR at aol.com Sat Nov 4 20:22:19 2006 From: KKSKAREBEAR at aol.com (KKSKAREBEAR at aol.com) Date: Sat, 4 Nov 2006 14:22:19 EST Subject: [Patches] Cheap Xanax Online - USA Pharmacy ELBE 0 Message-ID: how do you place an order ? thanks !! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061104/217d07bf/attachment.html From noreply at sourceforge.net Sun Nov 5 04:15:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 19:15:52 -0800 Subject: [Patches] [ python-Patches-1346572 ] Remove inconsistent behavior between import and zipimport Message-ID: Patches item #1346572, was opened at 2005-11-03 04:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346572&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Osvaldo Santana Neto (acidbase) Assigned to: Nobody/Anonymous (nobody) Summary: Remove inconsistent behavior between import and zipimport Initial Comment: Look the inconsistent behavior: $ ls modulo_c.pyc modulo_o.pyo $ zip modulos.zip modulo_o.pyo modulo_c.pyc adding: modulo_o.pyo (deflated 38%) adding: modulo_c.pyc (deflated 38%) $ ls modulo_c.pyc modulo_o.pyo modulos.zip $ python2.4 >>> import modulo_c modulo_c >>> import modulo_o ImportError: No module named modulo_o $ python2.4 -O >>> import modulo_c ImportError: No module named modulo_c >>> import modulo_o modulo_o $ rm *.pyc *.pyo $ ls modulos.zip $ PYTHONPATH=modulos.zip python2.4 >>> import modulo_c modulo_c >>> import modulo_o modulo_o $ PYTHONPATH=modulos.zip python2.4 -O >>> import modulo_c modulo_c >>> import modulo_o modulo_o ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 04:15 Message: Logged In: YES user_id=21627 The discussion on python-dev (both last year's and this year's) has shown that this is the wrong way of fixing the inconsistency. Instead, zipfile should stop importing .pyo files when -O isn't given. Rejecting the patch as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346572&group_id=5470 From noreply at sourceforge.net Sun Nov 5 04:23:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 19:23:19 -0800 Subject: [Patches] [ python-Patches-617779 ] Rational Reference Implementation Message-ID: Patches item #617779, was opened at 2002-10-02 23:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617779&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Rational Reference Implementation Initial Comment: This is a reference implementation of rational numbers (PEP239). It includes regression tests for rationals and changes to cPickle/pickle to support them. It has been tested on Solaris and Linux, but notably not Windows. This implementation does change the behaviour of future division to return a rational rather than a float. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 04:23 Message: Logged In: YES user_id=21627 Since the PEP was rejected, so is this patch. ---------------------------------------------------------------------- Comment By: Christopher A. Craig (ccraig) Date: 2002-10-16 03:55 Message: Logged In: YES user_id=135050 Attached rational-Nr uses rational literals in the form 3r or 3R ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=617779&group_id=5470 From noreply at sourceforge.net Sun Nov 5 10:11:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 01:11:20 -0800 Subject: [Patches] [ python-Patches-836088 ] Update htmllib to HTML 4.01 Message-ID: Patches item #836088, was opened at 2003-11-04 22:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Update htmllib to HTML 4.01 Initial Comment: The attached patch adds methods for all of the HTML 4.01 elements and rearranges things a bit. This version is incomplete. Still to do: * Expand test suite to exercise all the methods. * Change documentation to match. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 10:11 Message: Logged In: YES user_id=21627 I've updated the patch to integrate jlgijsbers' comments. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-07 23:53 Message: Logged In: YES user_id=469548 I used the list at http://www.w3.org/TR/html4/index/elements.html to check whether the right functions were used: col, frame, input and param should have do_tag() methods instead of start/end_tag(): they are empty tags in HTML 4.01. dd, dt and li should use start/end_tag() instead of do_tag(). They have an optional end tag in HTML 4.01. Oh, and I couldn't find a method for the 'div' element! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836088&group_id=5470 From arcyox at web2studio.com Sun Nov 5 12:27:59 2006 From: arcyox at web2studio.com (Tessa Madden) Date: Sun, 5 Nov 2006 12:27:59 +0100 Subject: [Patches] inspiring Message-ID: <98241E0.3EFFB1D@endorfin.tv> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061105/468fe2c5/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: dreamer.gif Type: image/gif Size: 8989 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061105/468fe2c5/attachment.gif From noreply at sourceforge.net Sun Nov 5 19:47:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 10:47:52 -0800 Subject: [Patches] [ python-Patches-632934 ] Problem at the end of misformed mailbox Message-ID: Patches item #632934, was opened at 2002-11-03 17:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: R?mi Peyronnet (rpeyron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Problem at the end of misformed mailbox Initial Comment: I had a problem with a not well formed mailbox (maybe ambiguous carriage return chars, due to both use under windows and linux) : the function mailbox.readlines (lib/mailbox.py:66) entered in an indefinite cycle. I found that the self.stop value was too big for the file, and that the index of self.pos could not go that far. The function readlines will call ever and ever readline, which will return always the same 1-length string. I solved this by comparing the fp.pos before and after the read operation. If it the same, we re probably at the end of the file, or there is a problem, and we should go out. As I do not know much about the Python internals, the following patch may not be good : C:\Python222\Lib>diff "Copie de mailbox.py" mailbox.py 63c63,68 < self.pos = self.fp.tell() --- > data = self.fp.readline(length) > self_fp_tell = self.fp.tell() > if self.pos == self_fp_tell: > return '' > else: > self.pos = self_fp_tell Regards ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-11-05 19:47 Message: Logged In: YES user_id=21627 After reviewing the code, I cannot see a reason for this problem to occur. self.stop originates from an earlier fp.tell() call, so it should be at most equal to the file size. Later readline calls should manage to read all of the file, then fp.tell should report the same value. The only way this might happen is that self.stop was somehow modified outside the standard library, or a _Subfile was created externally; I don't think the library should work around such a problem. So closing this as "works for me". If somebody manages to reproduce the problem, please include precise instructions on how to reproduce it. ---------------------------------------------------------------------- Comment By: R?mi Peyronnet (rpeyron) Date: 2004-11-22 23:51 Message: Logged In: YES user_id=641559 Sorry, I did not keep the mailbox. I may re-use this script in a few weeks/months, and if it does the same thing I will attach one. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-11 21:29 Message: Logged In: YES user_id=469548 R?mi, could you attach the mailbox (or a similar mailbox) that triggers the problem? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-03-21 21:03 Message: Logged In: YES user_id=31435 Assigned to Barry. Maybe y'all can polish this one off during the email sprint? ---------------------------------------------------------------------- Comment By: R?mi Peyronnet (rpeyron) Date: 2003-12-27 19:48 Message: Logged In: YES user_id=641559 This problem seems to exist in 2.3 version too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 From noreply at sourceforge.net Mon Nov 6 11:37:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 02:37:58 -0800 Subject: [Patches] [ python-Patches-1462525 ] URI parsing library Message-ID: Patches item #1462525, was opened at 2006-03-31 20:30 Message generated for change (Comment added) made by dalke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Jimenez (paulj) Assigned to: Nobody/Anonymous (nobody) Summary: URI parsing library Initial Comment: Per the original discussion at http://mail.python.org/pipermail/python-dev/2005-November/058301.html I'm submitting a library meant to deprecate the existing urlparse library. Questions and comments welcome. ---------------------------------------------------------------------- Comment By: Andrew Dalke (dalke) Date: 2006-11-06 03:37 Message: Logged In: YES user_id=190903 # new >>> uriparse.urljoin("http://spam/", "foo/bar") 'http://spam//foo/bar' >>> # existing >>> urlparse.urljoin("http://spam/", "foo/bar") 'http://spam/foo/bar' >>> Should not have the "//" again in your code. >>> import urlparse >>> import uriparse >>> urlparse.urljoin("http://blah", "/spam/") 'http://blah/spam/' >>> uriparse.urljoin("http://blah", "/spam/") 'http://blah/spam' >>> join 'http://www.guardian.co.uk/' u' ' urlparse: u'http://www.guardian.co.uk/ ' != uriparse: u'http://www.guardian.co.uk// ' join 'http://boingboing.net/' u' http://www.newsalloy.com/subrss4.gif' (yes, with a leading space in the relative URL) urlparse: u'http://boingboing.net/ http://www.newsalloy.com/subrss4.gif' != uriparse: u' http://www.newsalloy.com/subrss4.gif' I'll add a script to test wild web pages and compare urlparse and uriparse's respective urljoin methods. ALSO: Need an __all__ which excludes those *URIParser classes. ---------------------------------------------------------------------- Comment By: Paul Jimenez (paulj) Date: 2006-04-03 11:13 Message: Logged In: YES user_id=25150 Oops. fix some editing bugs. ---------------------------------------------------------------------- Comment By: Paul Jimenez (paulj) Date: 2006-04-02 15:19 Message: Logged In: YES user_id=25150 Naming: I also considered urlparse2 (ala urllib2) but liked having a name without a version number attached. rfc3986 would also work I suppose, but seems a bit... clunky. MailtoURIParser: You seem to have missed the point (probably due to my poor documentation): none of the *URIParser classes are meant to be directly used; they're just the default population of an extensible structure that URIParser uses to do the work of parsing. Let's move discussion to python-dev. I'll put changed/fixed/upgraded versions here as I adjust them due to feedback. Here's the first (adjusted due to your feedback). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 17:32 Message: Logged In: YES user_id=261020 Just a quick note listing some of the things I intend to worry about : 1. IRIs 2. Python unicode strings 3. Percent-encoding. See 1. and 2. 4. Interaction with other stdlib modules 5. RFC 3986 compliance (duh :-) It certainly seemed from a brief email discussion with Mike Brown a while back (who knows all this 10 times better than me) that 1., 2. and 3. are not so easily brushed under the carpet as you hope, but I'm very glad if you're right!-) I think these things need to be at least thought through by a few people before rushing a new module into the stdlib: we already have two modules containing outdated URL parsing code, we don't want to end up with a third one. Don't want to sound negative though, it's great that you wrote this! ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 17:20 Message: Logged In: YES user_id=261020 Some mostly-stylistic / minor comments on the patch from a quick skim (I hope to post some comments on the trickier issues later): Follow PEP 8. Some issues I noticed: - Inconsistent use of case: URI vs. Uri. - Triple-quoted docstrings should use " not ' for editor-friendliness. - Strings should not be abused as comments: If you mean to use a docstring, use a docstring; otherwise, use a comment (I'm referring here to your use of strings immediately *before* def statements). - import usage like import posixpath as ppath is usually frowned upon: just import posixpath. - Use of whitespace in e.g. dict displays and listcomps is non-standard. [x for x in y], not [ x for x in y ] - Indentation in docstrings is non-standard. - Docstring-writing conventions are non-standard. Other things: - Having read your original python-dev post, I still think UrlParser / URIParser could be simpler. I'll try and supply an actual suggested patch later. - MailToURIParser appears to support a different interface to all the others. If this is really necessary for standards or pragmatic reasons, those parse and unparse methods should just be separate functions. - Documentation for the module is missing. This would document the API and perhaps briefly explain the background (what's changed to require this new module) and correct usage, briefly explaining terms like "URI reference". Some well-chosen examples are always good, of course. - The tests should go in a separate module test/test_.py and follow the conventions there. - Would be very nice to explicitly reference RFC 3986 section numbers in the code. I'll try and do this when I review it properly. - Use of URI vs. URL distinction is incorrect. Finally, just BTW: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier """ The contemporary point of view among the working group that oversees URIs is that the terms URL and URN are context-dependent aspects of URI and rarely need to be distinguished. """ Heh, spot on! Still, like I said, I agree terms like "URI reference" deserve to be adopted. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 16:07 Message: Logged In: YES user_id=261020 This certainly seems needed (though I still haven't properly read 3986 and 3987, and not sure how IRIs fit in with everything else). Perhaps a bit late for 2.5. -1 on the name: makes it seem the difference between urlparse and uriparse is something to do with the already murky distinction between URIs and URLs. How about rfc3986? Prosaic, but hits the nail on the head. Must read those RFCs and review this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&group_id=5470 From noreply at sourceforge.net Mon Nov 6 11:41:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 02:41:49 -0800 Subject: [Patches] [ python-Patches-1462525 ] URI parsing library Message-ID: Patches item #1462525, was opened at 2006-03-31 20:30 Message generated for change (Comment added) made by dalke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Jimenez (paulj) Assigned to: Nobody/Anonymous (nobody) Summary: URI parsing library Initial Comment: Per the original discussion at http://mail.python.org/pipermail/python-dev/2005-November/058301.html I'm submitting a library meant to deprecate the existing urlparse library. Questions and comments welcome. ---------------------------------------------------------------------- Comment By: Andrew Dalke (dalke) Date: 2006-11-06 03:41 Message: Logged In: YES user_id=190903 Can't figure out how to add a file to this @#$%*@#%$ bug reporting system. Here's a checker to compare urljoin from urlparse and uriparse import urllib2 import urlparse import uriparse import BeautifulSoup for url in ( "http://python.org/", "http://www.perl.org/", ## "http://aspn.activestate.com/ASPN/Cookbook/Python", # they have \n in urls! "http://slashdot.org/", "http://cnn.com/", "http://bbc.co.uk/", "http://www.foxnews.com/", "http://reddit.com/", "http://yahoo.com/", "http://planetpython.org/", "http://www.slate.com/", "http://anarchaia.org/index.html", "http://www.ensembl.org/index.html", ): print "Processing", url f = urllib2.urlopen(url) soup = BeautifulSoup.BeautifulSoup(f) rel_url_list = [] for a in soup.findAll("a", href=True): rel_url_list.append(a["href"]) for img in soup.findAll("img", src=True): rel_url_list.append(img["src"]) for rel_url in rel_url_list: rel_url = rel_url.strip() url_joined = urlparse.urljoin(url, rel_url) uri_joined = uriparse.urljoin(url, rel_url) if url_joined != uri_joined: # urijoin can add an extra '/' ## if url_joined == uri_joined+"/": ## continue ## if url_joined.replace("//", "/") == uri_joined.replace("//", "/"): ## continue ## # 'http://cnn.com/' u'/cnnsi/scorecard/?cnn=yes' ## # url_joined == u'http://cnn.com/cnnsi/scorecard/?cnn=yes' ## # uri_joined == u'http://cnn.com/cnnsi/scorecard?cnn=yes' ## if url_joined.replace("/?", "?") == uri_joined: ## continue print repr(url), repr(rel_url) print " ", repr(url_joined), "!=", repr(uri_joined) ---------------------------------------------------------------------- Comment By: Andrew Dalke (dalke) Date: 2006-11-06 03:37 Message: Logged In: YES user_id=190903 # new >>> uriparse.urljoin("http://spam/", "foo/bar") 'http://spam//foo/bar' >>> # existing >>> urlparse.urljoin("http://spam/", "foo/bar") 'http://spam/foo/bar' >>> Should not have the "//" again in your code. >>> import urlparse >>> import uriparse >>> urlparse.urljoin("http://blah", "/spam/") 'http://blah/spam/' >>> uriparse.urljoin("http://blah", "/spam/") 'http://blah/spam' >>> join 'http://www.guardian.co.uk/' u' ' urlparse: u'http://www.guardian.co.uk/ ' != uriparse: u'http://www.guardian.co.uk// ' join 'http://boingboing.net/' u' http://www.newsalloy.com/subrss4.gif' (yes, with a leading space in the relative URL) urlparse: u'http://boingboing.net/ http://www.newsalloy.com/subrss4.gif' != uriparse: u' http://www.newsalloy.com/subrss4.gif' I'll add a script to test wild web pages and compare urlparse and uriparse's respective urljoin methods. ALSO: Need an __all__ which excludes those *URIParser classes. ---------------------------------------------------------------------- Comment By: Paul Jimenez (paulj) Date: 2006-04-03 11:13 Message: Logged In: YES user_id=25150 Oops. fix some editing bugs. ---------------------------------------------------------------------- Comment By: Paul Jimenez (paulj) Date: 2006-04-02 15:19 Message: Logged In: YES user_id=25150 Naming: I also considered urlparse2 (ala urllib2) but liked having a name without a version number attached. rfc3986 would also work I suppose, but seems a bit... clunky. MailtoURIParser: You seem to have missed the point (probably due to my poor documentation): none of the *URIParser classes are meant to be directly used; they're just the default population of an extensible structure that URIParser uses to do the work of parsing. Let's move discussion to python-dev. I'll put changed/fixed/upgraded versions here as I adjust them due to feedback. Here's the first (adjusted due to your feedback). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 17:32 Message: Logged In: YES user_id=261020 Just a quick note listing some of the things I intend to worry about : 1. IRIs 2. Python unicode strings 3. Percent-encoding. See 1. and 2. 4. Interaction with other stdlib modules 5. RFC 3986 compliance (duh :-) It certainly seemed from a brief email discussion with Mike Brown a while back (who knows all this 10 times better than me) that 1., 2. and 3. are not so easily brushed under the carpet as you hope, but I'm very glad if you're right!-) I think these things need to be at least thought through by a few people before rushing a new module into the stdlib: we already have two modules containing outdated URL parsing code, we don't want to end up with a third one. Don't want to sound negative though, it's great that you wrote this! ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 17:20 Message: Logged In: YES user_id=261020 Some mostly-stylistic / minor comments on the patch from a quick skim (I hope to post some comments on the trickier issues later): Follow PEP 8. Some issues I noticed: - Inconsistent use of case: URI vs. Uri. - Triple-quoted docstrings should use " not ' for editor-friendliness. - Strings should not be abused as comments: If you mean to use a docstring, use a docstring; otherwise, use a comment (I'm referring here to your use of strings immediately *before* def statements). - import usage like import posixpath as ppath is usually frowned upon: just import posixpath. - Use of whitespace in e.g. dict displays and listcomps is non-standard. [x for x in y], not [ x for x in y ] - Indentation in docstrings is non-standard. - Docstring-writing conventions are non-standard. Other things: - Having read your original python-dev post, I still think UrlParser / URIParser could be simpler. I'll try and supply an actual suggested patch later. - MailToURIParser appears to support a different interface to all the others. If this is really necessary for standards or pragmatic reasons, those parse and unparse methods should just be separate functions. - Documentation for the module is missing. This would document the API and perhaps briefly explain the background (what's changed to require this new module) and correct usage, briefly explaining terms like "URI reference". Some well-chosen examples are always good, of course. - The tests should go in a separate module test/test_.py and follow the conventions there. - Would be very nice to explicitly reference RFC 3986 section numbers in the code. I'll try and do this when I review it properly. - Use of URI vs. URL distinction is incorrect. Finally, just BTW: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier """ The contemporary point of view among the working group that oversees URIs is that the terms URL and URN are context-dependent aspects of URI and rarely need to be distinguished. """ Heh, spot on! Still, like I said, I agree terms like "URI reference" deserve to be adopted. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-04-01 16:07 Message: Logged In: YES user_id=261020 This certainly seems needed (though I still haven't properly read 3986 and 3987, and not sure how IRIs fit in with everything else). Perhaps a bit late for 2.5. -1 on the name: makes it seem the difference between urlparse and uriparse is something to do with the already murky distinction between URIs and URLs. How about rfc3986? Prosaic, but hits the nail on the head. Must read those RFCs and review this... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462525&group_id=5470 From noreply at sourceforge.net Mon Nov 6 18:19:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 09:19:38 -0800 Subject: [Patches] [ python-Patches-1587674 ] Patch for #1586414 to avoid fragmentation on Windows Message-ID: Patches item #1587674, was opened at 2006-10-31 05:05 Message generated for change (Comment added) made by enochjul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1586414 to avoid fragmentation on Windows Initial Comment: Add a call to file.truncate() to inform Windows of the size of the target file in makefile(). This helps guide cluster allocation in NTFS to avoid fragmentation. ---------------------------------------------------------------------- >Comment By: Enoch Julias (enochjul) Date: 2006-11-06 17:19 Message: Logged In: YES user_id=6071 I have not really tested FAT/FAT32 yet as I don't use these filesystems now. The Disk Defragmenter tool in Windows 2000/XP shows the number of files/directories fragmented in its report. NTFS does handle growing files, but the operating system can only do so much without knowing the size of the file. Extracting from archives consisting of only several files does not cause fragmentation. However, if the archive has many files, it is much more likely that the default algorithm will fail to allocate contiguous clusters for some files. It may also depend on the amount of free space fragmentation on a particular partition and whether other processes are writing to other files in the same partition. Some details of the cluster allocation algorithm used in Windows can be found at http://support.microsoft.com/kb/841551. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-01 15:27 Message: Logged In: YES user_id=642936 Is this merely an NTFS problem or is it the same with FAT fs? How do you detect file fragmentation? Doesn't this problem apply to all other modules or scripts that write to file objects as well? Shouldn't a decent filesystem be able to handle growing files in a correct manner? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 From noreply at sourceforge.net Mon Nov 6 22:52:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 13:52:36 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 23:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Mon Nov 6 22:57:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 13:57:27 -0800 Subject: [Patches] [ python-Patches-1587674 ] Patch for #1586414 to avoid fragmentation on Windows Message-ID: Patches item #1587674, was opened at 2006-10-31 06:05 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1586414 to avoid fragmentation on Windows Initial Comment: Add a call to file.truncate() to inform Windows of the size of the target file in makefile(). This helps guide cluster allocation in NTFS to avoid fragmentation. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-06 22:57 Message: Logged In: YES user_id=642936 Personally, I think disk defragmenters are evil ;-) They create the need that they are supposed to satisfy at the same time. On Linux we have no defragmenters, so we don't bother about it. I think your proposal is some kind of a performance hack for a particular filesystem. In principle, this problem exists for all filesystems on all platforms. Fragmentation is IMO a filesystem's problem and is not so much a state but more like a process. Filesystem fragment over time and you can't do anything about it. For those people who care, disk fragmenter were invented. It is not tarfile.py's job to care about a fragmented filesystem, that's simply too low level. I admit that it is a small patch, but I'm -1 on having this applied. ---------------------------------------------------------------------- Comment By: Enoch Julias (enochjul) Date: 2006-11-06 18:19 Message: Logged In: YES user_id=6071 I have not really tested FAT/FAT32 yet as I don't use these filesystems now. The Disk Defragmenter tool in Windows 2000/XP shows the number of files/directories fragmented in its report. NTFS does handle growing files, but the operating system can only do so much without knowing the size of the file. Extracting from archives consisting of only several files does not cause fragmentation. However, if the archive has many files, it is much more likely that the default algorithm will fail to allocate contiguous clusters for some files. It may also depend on the amount of free space fragmentation on a particular partition and whether other processes are writing to other files in the same partition. Some details of the cluster allocation algorithm used in Windows can be found at http://support.microsoft.com/kb/841551. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-01 16:27 Message: Logged In: YES user_id=642936 Is this merely an NTFS problem or is it the same with FAT fs? How do you detect file fragmentation? Doesn't this problem apply to all other modules or scripts that write to file objects as well? Shouldn't a decent filesystem be able to handle growing files in a correct manner? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 From noreply at sourceforge.net Mon Nov 6 23:52:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 14:52:02 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-07 07:52 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-07 08:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Tue Nov 7 14:32:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 05:32:28 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 22:32 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=1591996&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Tue Nov 7 14:40:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 05:40:41 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 22:32 Message generated for change (Settings changed) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 Please note that this 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: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Tue Nov 7 16:37:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 07:37:11 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 23:52 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-07 17:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-07 00:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Tue Nov 7 16:37:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 07:37:24 -0800 Subject: [Patches] [ python-Patches-1589070 ] MacPython Build Installer - Typos and Style corrections Message-ID: Patches item #1589070, was opened at 2006-11-02 06:44 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython Build Installer - Typos and Style corrections Initial Comment: * Corrected many typos (such as "IDLE is an IDLE" instead of "IDLE is an IDE"); * Simplified SRCDIR guessing; * PEP8 style; Includes patch #1589013 ("Univeral" MacPython). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-11-07 16:37 Message: Logged In: YES user_id=580910 The change to SRCDIR looks bogus and even if it works I find the current version more readable. That will definitely not go in. I will apply the typo fixes, and may do the same with the style changes. BTW. Humberto, it would be better to split the formatting changes from functional changes in future patches. We now had to hunt down the patch fragments that weren't formatting changes. Anyway, thanks for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-11-02 13:51 Message: Logged In: YES user_id=45365 Ronald, aside from a number of typo fixes (it took me 5 minutes to see that there's an "s" missing in "Univeral MacPython" :-) there's also some changes in the logic; those probably need some eyeballing over (the changes to SRCDIR look a bit suspect). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 From noreply at sourceforge.net Tue Nov 7 16:39:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 07:39:19 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 13:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 Please note that this 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: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) >Assigned to: Martin v. L?wis (loewis) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 15:39 Message: Logged In: YES user_id=849994 Attaching to Martin since the mentioned revision is his. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Tue Nov 7 16:48:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 07:48:20 -0800 Subject: [Patches] [ python-Patches-1592072 ] PyErr_CheckSignals returns -1 on error, not 1 Message-ID: Patches item #1592072, was opened at 2006-11-07 15:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592072&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: PyErr_CheckSignals returns -1 on error, not 1 Initial Comment: Documentation for PyErr_CheckSignals [1] says "If an exception is raised the error indicator is set and the function returns 1; otherwise the function returns 0.". But the code I see tells me the function returns -1 on error. I posted on the ML [2] and got no reply in over a month, so GvR suggested to fix the docs (patch attached). [1] http://docs.python.org/api/exceptionHandling.html#l2h-115 [2] http://mail.python.org/pipermail/python-dev/2006-September/068994.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592072&group_id=5470 From noreply at sourceforge.net Tue Nov 7 16:55:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 07:55:03 -0800 Subject: [Patches] [ python-Patches-1589070 ] MacPython Build Installer - Typos and Style corrections Message-ID: Patches item #1589070, was opened at 2006-11-02 03:44 Message generated for change (Comment added) made by virtualspirit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython Build Installer - Typos and Style corrections Initial Comment: * Corrected many typos (such as "IDLE is an IDLE" instead of "IDLE is an IDE"); * Simplified SRCDIR guessing; * PEP8 style; Includes patch #1589013 ("Univeral" MacPython). ---------------------------------------------------------------------- >Comment By: Humberto Di?genes (virtualspirit) Date: 2006-11-07 13:55 Message: Logged In: YES user_id=736405 Yes, after Jack's comment I noticed it was a really bad idea to mix these changes. Thanks for accepting it anyway! :) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-11-07 13:37 Message: Logged In: YES user_id=580910 The change to SRCDIR looks bogus and even if it works I find the current version more readable. That will definitely not go in. I will apply the typo fixes, and may do the same with the style changes. BTW. Humberto, it would be better to split the formatting changes from functional changes in future patches. We now had to hunt down the patch fragments that weren't formatting changes. Anyway, thanks for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-11-02 10:51 Message: Logged In: YES user_id=45365 Ronald, aside from a number of typo fixes (it took me 5 minutes to see that there's an "s" missing in "Univeral MacPython" :-) there's also some changes in the logic; those probably need some eyeballing over (the changes to SRCDIR look a bit suspect). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 From noreply at sourceforge.net Tue Nov 7 17:01:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 08:01:12 -0800 Subject: [Patches] [ python-Patches-1589070 ] MacPython Build Installer - Typos and Style corrections Message-ID: Patches item #1589070, was opened at 2006-11-02 06:44 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: MacPython Build Installer - Typos and Style corrections Initial Comment: * Corrected many typos (such as "IDLE is an IDLE" instead of "IDLE is an IDE"); * Simplified SRCDIR guessing; * PEP8 style; Includes patch #1589013 ("Univeral" MacPython). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-11-07 17:01 Message: Logged In: YES user_id=580910 I've commited the typo fixes as 52644 (trunk), 52645 (2.5 branch), 52646 (2.4 branch). The PEP8 style changes were applied in revision 52647 on the trunk. ---------------------------------------------------------------------- Comment By: Humberto Di?genes (virtualspirit) Date: 2006-11-07 16:55 Message: Logged In: YES user_id=736405 Yes, after Jack's comment I noticed it was a really bad idea to mix these changes. Thanks for accepting it anyway! :) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-11-07 16:37 Message: Logged In: YES user_id=580910 The change to SRCDIR looks bogus and even if it works I find the current version more readable. That will definitely not go in. I will apply the typo fixes, and may do the same with the style changes. BTW. Humberto, it would be better to split the formatting changes from functional changes in future patches. We now had to hunt down the patch fragments that weren't formatting changes. Anyway, thanks for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-11-02 13:51 Message: Logged In: YES user_id=45365 Ronald, aside from a number of typo fixes (it took me 5 minutes to see that there's an "s" missing in "Univeral MacPython" :-) there's also some changes in the logic; those probably need some eyeballing over (the changes to SRCDIR look a bit suspect). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589070&group_id=5470 From noreply at sourceforge.net Tue Nov 7 17:08:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 08:08:31 -0800 Subject: [Patches] [ python-Patches-1589013 ] Typo in Mac installer image name Message-ID: Patches item #1589013, was opened at 2006-11-02 02:40 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589013&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Humberto Di?genes (virtualspirit) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Typo in Mac installer image name Initial Comment: When installing Python on a Mac, the image is mounted with a wrong name: "Univeral" MacPython. $ mount | grep Py /dev/disk1s2 on /Volumes/Univeral MacPython 2.4.4 (...) ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-11-07 17:08 Message: Logged In: YES user_id=580910 As you've noticed I've applied that other patch. Thanks again. ---------------------------------------------------------------------- Comment By: Humberto Di?genes (virtualspirit) Date: 2006-11-02 06:47 Message: Logged In: YES user_id=736405 #1589070 contains an expanded version of this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589013&group_id=5470 From noreply at sourceforge.net Tue Nov 7 21:20:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 12:20:35 -0800 Subject: [Patches] [ python-Patches-1592250 ] Add missing elide argument to Text.search Message-ID: Patches item #1592250, was opened at 2006-11-07 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592250&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Add missing elide argument to Text.search Initial Comment: The Text widget's search method is missing the "elide" boolean argument. This patch corrects that. The elide argument has been supported for a long time by Tcl/Tk. I found it in the documentation for 8.3.5 but not 8.2.3. I tested it on 2.5 release, but verified that this portion of code has not changed in svn. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592250&group_id=5470 From noreply at sourceforge.net Wed Nov 8 06:53:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 21:53:04 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 13:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-07 21:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 07:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-06 14:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Wed Nov 8 07:28:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 22:28:11 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 05:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 Please note that this 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: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-07 22:28 Message: Logged In: YES user_id=33168 I fixed the problem slightly differently without casting, but rather checking the result. The patch also contains a test case. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 07:39 Message: Logged In: YES user_id=849994 Attaching to Martin since the mentioned revision is his. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Wed Nov 8 07:32:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 22:32:03 -0800 Subject: [Patches] [ python-Patches-1351020 ] PythonD DJGPP-specific patch set for porting to DOS. Message-ID: Patches item #1351020, was opened at 2005-11-08 09:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351020&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Decker (bdeck) Assigned to: Nobody/Anonymous (nobody) Summary: PythonD DJGPP-specific patch set for porting to DOS. Initial Comment: This is our initial recommendation for PythonD specific patch set running in DOS. Build requires at least DJGPP 2.04 32-bit DOS compiler (see http://www.delorie.com/djgpp/) and Watt-32 tcp/ip stack for DJGPP (see http://www.bgnett.no/~giva/). Operates under MSDOS, FreeDOS, Win32 and NT. Requires DOS mode long filename driver/TSR. See http://www.caddit.net/pythond.htm for details concerning the PythonD project. Diffed against 2.4.2 Final distribution. Diff script used: #! /usr/bin/bash for file in `find . -name *.orig -print` do export filename=`echo -n $file | sed -e 's/\.orig$//'` diff -c $file $filename >> pythond.diff done ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 07:32 Message: Logged In: YES user_id=21627 Can you please update the patch to the current subversion trunk? Please integrate 1351036 also, providing only a single patch. There are a number of problems with that patch: - what is the purpose of the site.py changes? Some parts (like a plain print statement) certainly have no place, other parts (like readline history support) traditionally belong to the user's PYTHONSTARTUP. Integrating them into Python might be an option, but that is independent of the patch. - please make the C block structure "work" even in presence of ifdefs. I.e. when you change the condition of a while loop, duplicate the entire while loop (which is just --i in one case), or introduce a macro to compute the condition. In several cases of posixmodule.c, introducing IS_SEP might be useful. - remove debugging code, even if commented out - why do you put the thread module into config.c.in? It's normally included through Setup.config - Don't use C++ comments ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351020&group_id=5470 From noreply at sourceforge.net Wed Nov 8 07:47:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 22:47:22 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 14:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 07:47 Message: Logged In: YES user_id=21627 I agree with Neal's patch, committed as r52662 and r52663. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 07:28 Message: Logged In: YES user_id=33168 I fixed the problem slightly differently without casting, but rather checking the result. The patch also contains a test case. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 16:39 Message: Logged In: YES user_id=849994 Attaching to Martin since the mentioned revision is his. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Wed Nov 8 08:06:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 23:06:27 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 22:32 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-11-08 16:06 Message: Logged In: YES user_id=1200846 Sorry for posting to closed entry, but this is related... Maybe similar patch is apropriate for PySequence_Contains in Objects/abstract.c like this? Thank you. Index: Objects/abstract.c =================================================================== --- Objects/abstract.c (revision 52664) +++ Objects/abstract.c (working copy) @@ -1719,7 +1719,9 @@ return (*sqm->sq_contains)(seq, ob); } result = _PySequence_IterSearch(seq, ob, PY_ITERSEARCH_CONTAINS); - return Py_SAFE_DOWNCAST(result, Py_ssize_t, int); + if (result >= 0) + return result > 0; + return -1; } /* Backwards compatibility */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 15:47 Message: Logged In: YES user_id=21627 I agree with Neal's patch, committed as r52662 and r52663. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 15:28 Message: Logged In: YES user_id=33168 I fixed the problem slightly differently without casting, but rather checking the result. The patch also contains a test case. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-08 00:39 Message: Logged In: YES user_id=849994 Attaching to Martin since the mentioned revision is his. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Wed Nov 8 08:37:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 23:37:15 -0800 Subject: [Patches] [ python-Patches-1351744 ] askyesnocancel helper for tkMessageBox Message-ID: Patches item #1351744, was opened at 2005-11-08 23:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351744&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Martin v. L?wis (loewis) Summary: askyesnocancel helper for tkMessageBox Initial Comment: This patch adds a an askyesnocancel helper to the tkMessageBox support module. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 08:37 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed (with a slight modification) as r52665. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1351744&group_id=5470 From noreply at sourceforge.net Wed Nov 8 08:43:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 23:43:29 -0800 Subject: [Patches] [ python-Patches-1591996 ] `in` for classic object causes segfault Message-ID: Patches item #1591996, was opened at 2006-11-07 14:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: `in` for classic object causes segfault Initial Comment: This code causes segfault. class Foo: pass foo = Foo() 1 in foo E:\python-dev>py a.py Exception exceptions.TypeError: "argument of type 'instance' is not iterable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection This bug seems to be introduced by revision 45644 change for Objects/classobject.c # -1 (error) is converted to 0 (False) I think this can be fixed by attached patch. Thank you. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 08:43 Message: Logged In: YES user_id=21627 It's not strictly necessary, IMO: PY_ITERSEARCH_CONTAINS is guaranteed to return -1, 0, 1, just as PySequence_Contains should. So the safe downcast is correct. IOW, your patch would have been correct, as well. I liked Neal's patch more, because it combines the error cases into a single return, and because it had a test case. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-11-08 08:06 Message: Logged In: YES user_id=1200846 Sorry for posting to closed entry, but this is related... Maybe similar patch is apropriate for PySequence_Contains in Objects/abstract.c like this? Thank you. Index: Objects/abstract.c =================================================================== --- Objects/abstract.c (revision 52664) +++ Objects/abstract.c (working copy) @@ -1719,7 +1719,9 @@ return (*sqm->sq_contains)(seq, ob); } result = _PySequence_IterSearch(seq, ob, PY_ITERSEARCH_CONTAINS); - return Py_SAFE_DOWNCAST(result, Py_ssize_t, int); + if (result >= 0) + return result > 0; + return -1; } /* Backwards compatibility */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 07:47 Message: Logged In: YES user_id=21627 I agree with Neal's patch, committed as r52662 and r52663. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 07:28 Message: Logged In: YES user_id=33168 I fixed the problem slightly differently without casting, but rather checking the result. The patch also contains a test case. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 16:39 Message: Logged In: YES user_id=849994 Attaching to Martin since the mentioned revision is his. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591996&group_id=5470 From noreply at sourceforge.net Wed Nov 8 08:46:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 23:46:16 -0800 Subject: [Patches] [ python-Patches-1592072 ] PyErr_CheckSignals returns -1 on error, not 1 Message-ID: Patches item #1592072, was opened at 2006-11-07 15:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592072&group_id=5470 Please note that this 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 Private: No Submitted By: Gustavo J. A. M. Carneiro (gustavo) >Assigned to: Georg Brandl (gbrandl) Summary: PyErr_CheckSignals returns -1 on error, not 1 Initial Comment: Documentation for PyErr_CheckSignals [1] says "If an exception is raised the error indicator is set and the function returns 1; otherwise the function returns 0.". But the code I see tells me the function returns -1 on error. I posted on the ML [2] and got no reply in over a month, so GvR suggested to fix the docs (patch attached). [1] http://docs.python.org/api/exceptionHandling.html#l2h-115 [2] http://mail.python.org/pipermail/python-dev/2006-September/068994.html ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-08 07:46 Message: Logged In: YES user_id=849994 Committed as rev. 52666, 52667 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592072&group_id=5470 From noreply at sourceforge.net Wed Nov 8 09:50:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 00:50:51 -0800 Subject: [Patches] [ python-Patches-1586791 ] better error msgs for some TypeErrors Message-ID: Patches item #1586791, was opened at 2006-10-29 19:44 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: better error msgs for some TypeErrors Initial Comment: This includes the wrong type for some objects' TypeErrors. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-08 09:50 Message: Logged In: YES user_id=89016 The patch includes unrelated changes to enumerate() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 From noreply at sourceforge.net Wed Nov 8 10:06:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 01:06:57 -0800 Subject: [Patches] [ python-Patches-1586791 ] better error msgs for some TypeErrors Message-ID: Patches item #1586791, was opened at 2006-10-29 18:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: better error msgs for some TypeErrors Initial Comment: This includes the wrong type for some objects' TypeErrors. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-08 09:06 Message: Logged In: YES user_id=849994 Thanks, fixed. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-08 08:50 Message: Logged In: YES user_id=89016 The patch includes unrelated changes to enumerate() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 From noreply at sourceforge.net Wed Nov 8 12:22:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 03:22:24 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 23:52 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-08 13:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 07:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 17:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-07 00:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Wed Nov 8 17:33:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 08:33:42 -0800 Subject: [Patches] [ python-Patches-1587674 ] Patch for #1586414 to avoid fragmentation on Windows Message-ID: Patches item #1587674, was opened at 2006-10-30 21:05 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1586414 to avoid fragmentation on Windows Initial Comment: Add a call to file.truncate() to inform Windows of the size of the target file in makefile(). This helps guide cluster allocation in NTFS to avoid fragmentation. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-11-08 08:33 Message: Logged In: YES user_id=341410 I disagree with user gustaebel. We should be adding automatic truncate calls for all possible supported platforms, in all places where it could make sense. Be it in tarfile, zipfile, where ever we can. It would make sense to write a function that can be called by all of those modules so that there is only one place to update if/when changes occur. If the function were not part of the public Python API, then it wouldn't need to wait until 2.6, unless it were considered a feature addition rather than bugfix. One would have to wait on a response from Martin or Anthony to know which it was, though I couldn't say for sure if operations that are generally performance enhancing are bugfixes or feature additions. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-06 13:57 Message: Logged In: YES user_id=642936 Personally, I think disk defragmenters are evil ;-) They create the need that they are supposed to satisfy at the same time. On Linux we have no defragmenters, so we don't bother about it. I think your proposal is some kind of a performance hack for a particular filesystem. In principle, this problem exists for all filesystems on all platforms. Fragmentation is IMO a filesystem's problem and is not so much a state but more like a process. Filesystem fragment over time and you can't do anything about it. For those people who care, disk fragmenter were invented. It is not tarfile.py's job to care about a fragmented filesystem, that's simply too low level. I admit that it is a small patch, but I'm -1 on having this applied. ---------------------------------------------------------------------- Comment By: Enoch Julias (enochjul) Date: 2006-11-06 09:19 Message: Logged In: YES user_id=6071 I have not really tested FAT/FAT32 yet as I don't use these filesystems now. The Disk Defragmenter tool in Windows 2000/XP shows the number of files/directories fragmented in its report. NTFS does handle growing files, but the operating system can only do so much without knowing the size of the file. Extracting from archives consisting of only several files does not cause fragmentation. However, if the archive has many files, it is much more likely that the default algorithm will fail to allocate contiguous clusters for some files. It may also depend on the amount of free space fragmentation on a particular partition and whether other processes are writing to other files in the same partition. Some details of the cluster allocation algorithm used in Windows can be found at http://support.microsoft.com/kb/841551. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-01 07:27 Message: Logged In: YES user_id=642936 Is this merely an NTFS problem or is it the same with FAT fs? How do you detect file fragmentation? Doesn't this problem apply to all other modules or scripts that write to file objects as well? Shouldn't a decent filesystem be able to handle growing files in a correct manner? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 From noreply at sourceforge.net Wed Nov 8 22:30:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 13:30:13 -0800 Subject: [Patches] [ python-Patches-1587674 ] Patch for #1586414 to avoid fragmentation on Windows Message-ID: Patches item #1587674, was opened at 2006-10-31 06:05 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for #1586414 to avoid fragmentation on Windows Initial Comment: Add a call to file.truncate() to inform Windows of the size of the target file in makefile(). This helps guide cluster allocation in NTFS to avoid fragmentation. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-08 22:30 Message: Logged In: YES user_id=642936 You both still fail to convince me and I still don't see need for action. The only case ATM where this addition makes sense (in your opinion) is the Windows OS when using the NTFS filesystem and certain conditions are met. NTFS has a preallocation algorithm to deal with this. We don't know if there is any advantage on FAT filesystems. On Linux for example there is a plethora of supported filesystems. Some of them may take advantage, others may not. Who knows? We can't even detect which filesystem type we are currently writing to. Apart from that, the behaviour of truncate(arg) with arg > filesize seems to be system-dependent. So, IMO this is a very special optimization targeted at a single platform. The TarFile class is easily subclassable, just override the makefile() method and add the two lines of code. I think that's what ActiveState's Python Cookbook is for. BTW, I like my files to grow bit by bit. In case of an error, I can detect if a file was not extracted completely by comparing the file sizes. Furthermore, a file that grows is more common and more what a programmer who uses this module might expect. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-11-08 17:33 Message: Logged In: YES user_id=341410 I disagree with user gustaebel. We should be adding automatic truncate calls for all possible supported platforms, in all places where it could make sense. Be it in tarfile, zipfile, where ever we can. It would make sense to write a function that can be called by all of those modules so that there is only one place to update if/when changes occur. If the function were not part of the public Python API, then it wouldn't need to wait until 2.6, unless it were considered a feature addition rather than bugfix. One would have to wait on a response from Martin or Anthony to know which it was, though I couldn't say for sure if operations that are generally performance enhancing are bugfixes or feature additions. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-06 22:57 Message: Logged In: YES user_id=642936 Personally, I think disk defragmenters are evil ;-) They create the need that they are supposed to satisfy at the same time. On Linux we have no defragmenters, so we don't bother about it. I think your proposal is some kind of a performance hack for a particular filesystem. In principle, this problem exists for all filesystems on all platforms. Fragmentation is IMO a filesystem's problem and is not so much a state but more like a process. Filesystem fragment over time and you can't do anything about it. For those people who care, disk fragmenter were invented. It is not tarfile.py's job to care about a fragmented filesystem, that's simply too low level. I admit that it is a small patch, but I'm -1 on having this applied. ---------------------------------------------------------------------- Comment By: Enoch Julias (enochjul) Date: 2006-11-06 18:19 Message: Logged In: YES user_id=6071 I have not really tested FAT/FAT32 yet as I don't use these filesystems now. The Disk Defragmenter tool in Windows 2000/XP shows the number of files/directories fragmented in its report. NTFS does handle growing files, but the operating system can only do so much without knowing the size of the file. Extracting from archives consisting of only several files does not cause fragmentation. However, if the archive has many files, it is much more likely that the default algorithm will fail to allocate contiguous clusters for some files. It may also depend on the amount of free space fragmentation on a particular partition and whether other processes are writing to other files in the same partition. Some details of the cluster allocation algorithm used in Windows can be found at http://support.microsoft.com/kb/841551. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-11-01 16:27 Message: Logged In: YES user_id=642936 Is this merely an NTFS problem or is it the same with FAT fs? How do you detect file fragmentation? Doesn't this problem apply to all other modules or scripts that write to file objects as well? Shouldn't a decent filesystem be able to handle growing files in a correct manner? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1587674&group_id=5470 From noreply at sourceforge.net Thu Nov 9 05:14:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 20:14:50 -0800 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 23:04 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-09 04:14 Message: Logged In: YES user_id=5571 What's the status of this? Is it going in? I have a need for it. Thanks. ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 19:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Thu Nov 9 06:21:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 21:21:06 -0800 Subject: [Patches] [ python-Patches-1352731 ] Small upgrades to platform.platform() Message-ID: Patches item #1352731, was opened at 2005-11-10 02:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: daishi harada (daishiharada) Assigned to: M.-A. Lemburg (lemburg) Summary: Small upgrades to platform.platform() Initial Comment: This patch updates platform.platform() to recognize some more Linux distributions. In addition, for RedHat-like distributions, will use the contents of the /etc/ to determine distname. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 06:21 Message: Logged In: YES user_id=21627 Marc-Andre, would you rather accept or reject this patch, because of the incompatibility? ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2006-10-10 01:22 Message: Logged In: YES user_id=493197 Thanks for the response. If by "break" you mean that for redhat-like distros the output of `python platform.py` would no longer necessarily be the same after the patch is applied, yes, that's true. However, that was the primary motivation for the patch - the current platform.py wasn't sufficiently discriminating for my purposes. In particular, the current platform.py ignores the first "field" of the contents of /etc/redhat-release, which I believe for ROCKS was the only portion which was changed from the redhat version on which it was based. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-10-09 20:31 Message: Logged In: YES user_id=38388 Sorry for the late reply. I must have missed the initial SF mail. I've had a look at the patch, but I'm not sure whether it can be accepted: wouldn't it break already recognized RedHat-like platforms ? ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-11-10 02:23 Message: Logged In: YES user_id=493197 assigning to lemberg as suggested in the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 From noreply at sourceforge.net Thu Nov 9 08:49:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 23:49:38 -0800 Subject: [Patches] [ python-Patches-1352731 ] Small upgrades to platform.platform() Message-ID: Patches item #1352731, was opened at 2005-11-10 02:19 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: daishi harada (daishiharada) Assigned to: M.-A. Lemburg (lemburg) Summary: Small upgrades to platform.platform() Initial Comment: This patch updates platform.platform() to recognize some more Linux distributions. In addition, for RedHat-like distributions, will use the contents of the /etc/ to determine distname. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-11-09 08:49 Message: Logged In: YES user_id=38388 I'm currently working on an updated version of platform.py that will include part of this patch, patch #1563842 for IronPython and better support for Jython. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 06:21 Message: Logged In: YES user_id=21627 Marc-Andre, would you rather accept or reject this patch, because of the incompatibility? ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2006-10-10 01:22 Message: Logged In: YES user_id=493197 Thanks for the response. If by "break" you mean that for redhat-like distros the output of `python platform.py` would no longer necessarily be the same after the patch is applied, yes, that's true. However, that was the primary motivation for the patch - the current platform.py wasn't sufficiently discriminating for my purposes. In particular, the current platform.py ignores the first "field" of the contents of /etc/redhat-release, which I believe for ROCKS was the only portion which was changed from the redhat version on which it was based. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-10-09 20:31 Message: Logged In: YES user_id=38388 Sorry for the late reply. I must have missed the initial SF mail. I've had a look at the patch, but I'm not sure whether it can be accepted: wouldn't it break already recognized RedHat-like platforms ? ---------------------------------------------------------------------- Comment By: daishi harada (daishiharada) Date: 2005-11-10 02:23 Message: Logged In: YES user_id=493197 assigning to lemberg as suggested in the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1352731&group_id=5470 From noreply at sourceforge.net Thu Nov 9 12:12:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 03:12:00 -0800 Subject: [Patches] [ python-Patches-838546 ] make pty.fork() allocate a controlling tty Message-ID: Patches item #838546, was opened at 2003-11-08 21:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: J Raynor (raynorj) Assigned to: Nobody/Anonymous (nobody) Summary: make pty.fork() allocate a controlling tty Initial Comment: pty.fork() does not allocate a controlling tty on systems that don't have os.forkpty(). The code for pty.fork() tries to use os.forkpty(), and if it isn't available, then it tries to do its work in python, but it doesn't work. The code does setup stdin, stdout, and stderr to use the slave device, but it needs to do an explicit open on the slave device to make it become a controlling tty. This patch is against pty.py from python 2.3, but the same change can be made to pty.py from python 2.2 and it works there. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 12:12 Message: Logged In: YES user_id=21627 I just looked at the source of the GNU C library, and it essentially does the same thing: in login_tty(), it does check whether ttyname returned a non-NULL string, and then just opens the terminal once. It might do the null check for a different reason; it's not certain that the fd really is a terminal. On systems that support TIOCSCTTY, glibc uses that instead. So thanks for the patch; I committed it as r52686 and r52687. There might be room for improvement, but that can come as a separate contribution. ---------------------------------------------------------------------- Comment By: J Raynor (raynorj) Date: 2003-11-11 02:03 Message: Logged In: YES user_id=904832 This works on aix 5.2, 5.1, and 4.3.3. It also works on hpux 10.20. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-10 07:38 Message: Logged In: YES user_id=21627 What systems did you test this on? I remember ttyname returning funny things on some systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=838546&group_id=5470 From noreply at sourceforge.net Thu Nov 9 12:27:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 03:27:55 -0800 Subject: [Patches] [ python-Patches-1592250 ] Add missing elide argument to Text.search Message-ID: Patches item #1592250, was opened at 2006-11-07 21:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592250&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Add missing elide argument to Text.search Initial Comment: The Text widget's search method is missing the "elide" boolean argument. This patch corrects that. The elide argument has been supported for a long time by Tcl/Tk. I found it in the documentation for 8.3.5 but not 8.2.3. I tested it on 2.5 release, but verified that this portion of code has not changed in svn. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 12:27 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52688. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1592250&group_id=5470 From noreply at sourceforge.net Thu Nov 9 13:04:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 04:04:28 -0800 Subject: [Patches] [ python-Patches-1589266 ] bdist_sunpkg distutils command Message-ID: Patches item #1589266, was opened at 2006-11-02 14:35 Message generated for change (Comment added) made by jholg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Holger (jholg) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_sunpkg distutils command Initial Comment: Hi, find attached a bdist_sunpkg distutils command class that implements creating a sun solaris package. This has been based on the python2.3 distutils but should work with newer ones, too. Note that a small patch to file_util is needed that adds the verbose/dry_run capabilities to the write_file function. At the moment, fancy things like dependency scripts and stuff are not supported. Holger ---------------------------------------------------------------------- >Comment By: Holger (jholg) Date: 2006-11-09 13:04 Message: Logged In: YES user_id=1315684 I'm currently clarifying this with my employer ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 01:15 Message: Logged In: YES user_id=21627 Are you willing to fill out the contribution form, at http://www.python.org/psf/contrib/ ---------------------------------------------------------------------- Comment By: Holger (jholg) Date: 2006-11-02 14:38 Message: Logged In: YES user_id=1315684 (uploaded file_util patch) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1589266&group_id=5470 From noreply at sourceforge.net Thu Nov 9 14:27:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 05:27:52 -0800 Subject: [Patches] [ python-Patches-1569798 ] Fix building the source within exec_prefix Message-ID: Patches item #1569798, was opened at 2006-10-03 10:24 Message generated for change (Comment added) made by benji2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569798&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Fix building the source within exec_prefix Initial Comment: [forwarded from http://bugs.debian.org/385336] when built under a subdirectory of exec_prefix, the build fails building the extensions. bug submitter writes: OK, after a debugging session, I found out why. It seems to be an upstream bug in distutils. See python2.5-2.5~c1/Lib/distutils/command/build_ext.py line 188+: if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') This code is executed only in the shared build. The if clause is here to determine whether we're running a correctly installed python or whether we're running python from its source tree. In our case (since we're building python itself atm), the condition *must* evaluate to false. However, this exact check looks very clumsy. On my build system, sys.executable == '/usr/src/debian/build/python2.5-2.5~c1/build-shared/python', sys.exec_prefix == '/usr', i.e. the condition is true and distutils thinks it's running on an already installed python distribution. The reason is that I'm building below the 'install prefix' directory (in /usr/src/...). In contrast, on the Debian buildd machines, this is performed in /build/buildd/.... which does not trigger the distutils bug. ---------------------------------------------------------------------- Comment By: Benjamin Thyreau (benji2) Date: 2006-11-09 14:27 Message: Logged In: YES user_id=140916 Hi, I seem to have a very related problem too, since i also traced it back to Lib/distutils/command/build_ext.py line 188. Summary, when Python is installed with both --enable-shared and --prefix, distutils generated compilations lines (rightly) add -lpython2.5 but does NOT add the corresponding -L (which is, PREFIX/lib by default ). I had to manually add self.library_dirs.append(os.path.join(sys.prefix, "lib")) on line 190 to quick fix that. Also, the abovementioned test "string.find(sys.executable, sys.exec_prefix)!=-1" doesn't have the intended effect on my system either, because of symlinks (oddly enough it works when running from IPython, maybe it resolves paths differently) Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569798&group_id=5470 From noreply at sourceforge.net Thu Nov 9 14:55:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 05:55:59 -0800 Subject: [Patches] [ python-Patches-1514544 ] mailbox: use fsync() to ensure data is really on disk Message-ID: Patches item #1514544, was opened at 2006-06-29 14:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: use fsync() to ensure data is really on disk Initial Comment: The mailbox module currently does nothing to ensure messages/indexes are physically on disk when the flush() method returns or message files are closed. This patch adds functions _sync_flush and _sync_close to flush and fsync() a file object, and in the latter case close it afterwards. _sync_close is then used where needed throughout the code. (For various reasons the current implementation only ever requires a sync immediately before closing a file, but _sync_flush is provided for future use.) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 08:55 Message: Logged In: YES user_id=11375 I've tweaked the top comment in the patch a little and applied it to the trunk in rev. 52692 (so it'll be in 2.6). Because it's an internal API change, I'm cautious about applying it to the 25-maint branch, but will raise the issue on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 From noreply at sourceforge.net Thu Nov 9 14:56:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 05:56:40 -0800 Subject: [Patches] [ python-Patches-1514544 ] mailbox: use fsync() to ensure data is really on disk Message-ID: Patches item #1514544, was opened at 2006-06-29 14:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: use fsync() to ensure data is really on disk Initial Comment: The mailbox module currently does nothing to ensure messages/indexes are physically on disk when the flush() method returns or message files are closed. This patch adds functions _sync_flush and _sync_close to flush and fsync() a file object, and in the latter case close it afterwards. _sync_close is then used where needed throughout the code. (For various reasons the current implementation only ever requires a sync immediately before closing a file, but _sync_flush is provided for future use.) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 08:56 Message: Logged In: YES user_id=11375 Oops! I forgot to say: thank you for the patch! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 08:55 Message: Logged In: YES user_id=11375 I've tweaked the top comment in the patch a little and applied it to the trunk in rev. 52692 (so it'll be in 2.6). Because it's an internal API change, I'm cautious about applying it to the 25-maint branch, but will raise the issue on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 From noreply at sourceforge.net Thu Nov 9 15:41:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 06:41:43 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 23:52 Message generated for change (Settings changed) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) >Assigned to: Neal Norwitz (nnorwitz) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 13:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 07:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 17:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-07 00:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Thu Nov 9 15:43:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 06:43:04 -0800 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 15:04 Message generated for change (Comment added) made by noonian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- >Comment By: James Eagan (noonian) Date: 2006-11-09 06:43 Message: Logged In: YES user_id=31389 Nagle: I haven't heard anything from anyone besides you and jbowes abou this patch here or on the python-dev list, and I haven't had time to follow up. You might have more success via the email list. (Or, if any of the python maintainers is reading this, do you have any suggestions to make this patch more attractive?) ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-08 20:14 Message: Logged In: YES user_id=5571 What's the status of this? Is it going in? I have a need for it. Thanks. ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 12:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Thu Nov 9 16:20:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 07:20:03 -0800 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 23:04 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-09 15:20 Message: Logged In: YES user_id=908 > This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). Are you sure it's a good idea to have this kind of 'global' control over certification authorities? Global configurations are handy at first, but they come back and bite us when we least expect it... ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2006-11-09 14:43 Message: Logged In: YES user_id=31389 Nagle: I haven't heard anything from anyone besides you and jbowes abou this patch here or on the python-dev list, and I haven't had time to follow up. You might have more success via the email list. (Or, if any of the python maintainers is reading this, do you have any suggestions to make this patch more attractive?) ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-09 04:14 Message: Logged In: YES user_id=5571 What's the status of this? Is it going in? I have a need for it. Thanks. ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 20:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Thu Nov 9 22:17:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 13:17:54 -0800 Subject: [Patches] [ python-Patches-1514543 ] mailbox (Maildir): avoid losing messages on name clash Message-ID: Patches item #1514543, was opened at 2006-06-29 14:26 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 6 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (Maildir): avoid losing messages on name clash Initial Comment: The Maildir specification says that messages should be moved into the "new" directory using link()/unlink(), not rename(). This isn't for compatibility with ancient Unixes, but to avoid overwriting an existing message if the "unique" name turns out not to be unique after all. (In the current implementation this can happen if the system clock only has whole-second resolution and deliveries are being done in subprocesses, or the clock has been adjusted backwards, or two machines have the same hostname.) Similarly, the file in "tmp" should be created O_EXCL. This patch implements these requirements, falling back to rename() if link() is unavailable (where on Windows at least, it's supposed to fail if the destination exists), and raising ExternalClashError when the link/rename fails due to the name already being taken in "new". ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 16:17 Message: Logged In: YES user_id=11375 Applied to the trunk in rev. 52712; will backport to 25-maint after seeing what happens on the buildbots. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 From noreply at sourceforge.net Thu Nov 9 22:25:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 13:25:40 -0800 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 16:25 Message: Logged In: YES user_id=11375 Some bits of this patch (the URL change, using True/False and sys.exc_info()) are uncontroversial. Shall I go ahead and try to apply those bits, or can the debate on the changes converge to a decision? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 18:31 Message: Logged In: YES user_id=764593 (Responding to the patch, not directly to the conversation) (1) (around lines 234) Do you really want two test cases to compare equal because they have the same name, even if that name is the default runTest? (2) Have you made sense of the UnboundMethodType case? As nearly as I can figure, the old behavior was to run call the test case with a method name (which by default tried to run it, using that string as a TestResult?!?, and then returned None), and the new behavior just wraps this None in a TestSuite. (3) After patch, the callable case has a "return test" which is dead code, because the other branches either raised or returned on their own. (4) Changing the raise from ValueError to TypeError would make sense if not for backwards compatibility. Could you use a custom error that inherits from both? Please don't let these comments get you down; this is code that needs cleaning. (The changes to not special-case jython and to not rewalk the mro are particularly good -- because they don't do anything, having them in the code is misleading.) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 17:39 Message: Logged In: YES user_id=1344176 Jim: > (Is there something they could do to the TestCase() that > would start to fail if you wrap it in a TestSuite()? > Remember that they might have local standards saying "only > one test class per file" or something, so they might never > have gotten a real suite back in the past.) Off the top of my head: - TestSuite.run() requires a TestResult instance to be passed in where TestCase.run()'s result parameter is optional. - TestSuite doesn't have TestCase's shortDescription() or id() method. - Assignment to a TestCase instance's failureException attribute will affect the object's run() method, whereas the same assignment on a TestSuite will have no effect. IMHO none of these is significant enough to block that particular section of the patch. Remember that we're talking about a behaviour that's only triggered when the given name resolves to a callable and that callable returns a TestCase instance when invoked. I don't like the idea of keeping around long-standing minor bugs just because someone, somewhere might be using them. Can anyone produce a real example where someone is relying on this behaviour? I'll send a message to c.l.p on Monday and see if anyone in that wider audience can come up with concrete cases where these behaviours are mission-critical. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Fri Nov 10 14:08:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 05:08:24 -0800 Subject: [Patches] [ python-Patches-1514544 ] mailbox: use fsync() to ensure data is really on disk Message-ID: Patches item #1514544, was opened at 2006-06-29 14:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: use fsync() to ensure data is really on disk Initial Comment: The mailbox module currently does nothing to ensure messages/indexes are physically on disk when the flush() method returns or message files are closed. This patch adds functions _sync_flush and _sync_close to flush and fsync() a file object, and in the latter case close it afterwards. _sync_close is then used where needed throughout the code. (For various reasons the current implementation only ever requires a sync immediately before closing a file, but _sync_flush is provided for future use.) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-10 08:08 Message: Logged In: YES user_id=11375 Committed to the 25-maint branch in rev. 52718. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 08:56 Message: Logged In: YES user_id=11375 Oops! I forgot to say: thank you for the patch! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 08:55 Message: Logged In: YES user_id=11375 I've tweaked the top comment in the patch a little and applied it to the trunk in rev. 52692 (so it'll be in 2.6). Because it's an internal API change, I'm cautious about applying it to the 25-maint branch, but will raise the issue on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 From noreply at sourceforge.net Fri Nov 10 14:24:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 05:24:45 -0800 Subject: [Patches] [ python-Patches-1514543 ] mailbox (Maildir): avoid losing messages on name clash Message-ID: Patches item #1514543, was opened at 2006-06-29 14:26 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 6 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (Maildir): avoid losing messages on name clash Initial Comment: The Maildir specification says that messages should be moved into the "new" directory using link()/unlink(), not rename(). This isn't for compatibility with ancient Unixes, but to avoid overwriting an existing message if the "unique" name turns out not to be unique after all. (In the current implementation this can happen if the system clock only has whole-second resolution and deliveries are being done in subprocesses, or the clock has been adjusted backwards, or two machines have the same hostname.) Similarly, the file in "tmp" should be created O_EXCL. This patch implements these requirements, falling back to rename() if link() is unavailable (where on Windows at least, it's supposed to fail if the destination exists), and raising ExternalClashError when the link/rename fails due to the name already being taken in "new". ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-10 08:24 Message: Logged In: YES user_id=11375 Applied to 25-maint in rev. 52720. Thanks for the patch! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 16:17 Message: Logged In: YES user_id=11375 Applied to the trunk in rev. 52712; will backport to 25-maint after seeing what happens on the buildbots. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 From noreply at sourceforge.net Sat Nov 11 01:27:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 16:27:40 -0800 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-11-10 19:27 Message: Logged In: YES user_id=764593 Doing the obvious parts first makes sense to me, because it leaves a cleaner slate for comparisons. On the other hand, the job still won't be done, so if Collin wants it all at once, that would be up to him. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 16:25 Message: Logged In: YES user_id=11375 Some bits of this patch (the URL change, using True/False and sys.exc_info()) are uncontroversial. Shall I go ahead and try to apply those bits, or can the debate on the changes converge to a decision? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 18:31 Message: Logged In: YES user_id=764593 (Responding to the patch, not directly to the conversation) (1) (around lines 234) Do you really want two test cases to compare equal because they have the same name, even if that name is the default runTest? (2) Have you made sense of the UnboundMethodType case? As nearly as I can figure, the old behavior was to run call the test case with a method name (which by default tried to run it, using that string as a TestResult?!?, and then returned None), and the new behavior just wraps this None in a TestSuite. (3) After patch, the callable case has a "return test" which is dead code, because the other branches either raised or returned on their own. (4) Changing the raise from ValueError to TypeError would make sense if not for backwards compatibility. Could you use a custom error that inherits from both? Please don't let these comments get you down; this is code that needs cleaning. (The changes to not special-case jython and to not rewalk the mro are particularly good -- because they don't do anything, having them in the code is misleading.) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 17:39 Message: Logged In: YES user_id=1344176 Jim: > (Is there something they could do to the TestCase() that > would start to fail if you wrap it in a TestSuite()? > Remember that they might have local standards saying "only > one test class per file" or something, so they might never > have gotten a real suite back in the past.) Off the top of my head: - TestSuite.run() requires a TestResult instance to be passed in where TestCase.run()'s result parameter is optional. - TestSuite doesn't have TestCase's shortDescription() or id() method. - Assignment to a TestCase instance's failureException attribute will affect the object's run() method, whereas the same assignment on a TestSuite will have no effect. IMHO none of these is significant enough to block that particular section of the patch. Remember that we're talking about a behaviour that's only triggered when the given name resolves to a callable and that callable returns a TestCase instance when invoked. I don't like the idea of keeping around long-standing minor bugs just because someone, somewhere might be using them. Can anyone produce a real example where someone is relying on this behaviour? I'll send a message to c.l.p on Monday and see if anyone in that wider audience can come up with concrete cases where these behaviours are mission-critical. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Sat Nov 11 04:36:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 19:36:04 -0800 Subject: [Patches] [ python-Patches-1594554 ] tkSimpleDialog freezes when apply raises exception Message-ID: Patches item #1594554, was opened at 2006-11-11 12:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1594554&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: tkSimpleDialog freezes when apply raises exception Initial Comment: Hello. I found attached "a.py" freezes when I clicked "OK" button. (Toplevel widget is no responsible anymore) If this is a bug, is "a.patch" right fix? Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1594554&group_id=5470 From noreply at sourceforge.net Sat Nov 11 14:23:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 05:23:17 -0800 Subject: [Patches] [ python-Patches-1038854 ] Fix struct.pack on 64-bit archs (broken on 2.*) Message-ID: Patches item #1038854, was opened at 2004-10-02 07:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Stefan Grundmann (sgatwasetde) Assigned to: Nobody/Anonymous (nobody) Summary: Fix struct.pack on 64-bit archs (broken on 2.*) Initial Comment: Description: The code in the struct module assumes that sizeof(long) == sizeof(int) which is wrong on (most) 64-bit architectures (linux on amd64 with a 32-bit userland is an exception). How To Repeat: on a 32-bit platform struct.pack behaves as expected: $ uname -m -r -s FreeBSD 4.10-STABLE i386 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert on a 64-bit platform it treats integers as longs (it does not check for over/underflows and returns the lower 4 byte): $ uname -m -r -s FreeBSD 5.2-CURRENT sparc64 $ python -c "import struct; print repr(struct.pack('I', 4294967296))" '\x00\x00\x00\x00' Fix: in python/python/dist/src/Modules/structmodule.c: np_uint() and np_int() have to check for over/underflows using MAX_UINT, MAX_INT, MIN_INT as np_ushort() and np_short() already do for MAX_USHORT, ... the attached patch does this (diff was generated using diff -rNu and Revision 2.62 of python/python/dist/src/Modules/structmodule.c) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 14:23 Message: Logged In: YES user_id=21627 I believe this has been fixed in Python 2.5 in a different way (involving a rewrite of the struct module); closing as out-of-date. sgatwasetde, if you think further changes are needed, please submit a new patch. ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-11-11 23:20 Message: Logged In: YES user_id=1131807 Issuing a warning instead of an error might be a good idea (to give the user-base some time adapt). But then we still have to deal with the fact that the some python modules are broken on 64 bit (at least big-endian). The gzip module for example does not work correctly even with the old code (because of stuctmodule). And there is user code out there that relies on correct overflow detection (which was the reason i submitted the patch). Another way would be to omit the overflow detection completely and heave the user take care of it. This will break a lot of applications but is imho more consistent then the old behavior (check some cases on some architectures). Personally i would like to have a structmodule in python 2.4 that works a one would expect (overflow detection) but that is not my decision to make. The fact that code which is under control of the python project uses struct.pack (...) in erroneous ways should be fixed (even if it does work on 32 bit archs atm). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-10 22:31 Message: Logged In: YES user_id=4771 This indicate that similar breakage will probably occur in user code if we add range checking. Do we want to take the risk? It looks overkill, but what about issuing a warning and turning it into an error in the next version? ---------------------------------------------------------------------- Comment By: Stefan Grundmann (sgatwasetde) Date: 2004-11-10 09:36 Message: Logged In: YES user_id=1131807 The patch breaks test_binhex on 32 and 64 bit architectures because Lib/binhex.py is using struct.pack('>h' ...) to pack an unsigned short (which is wrong but does work with the current version of Modules/structmodule.c because of the lack of range checking). The patch breaks test_gzip (and test_tarfile) on 64 bit architectures because Lib/gzip.py is using write32 (which uses to pack('I',...) fail to detect the overflow in the same way? If so, can you also provide the patch for these 4 other routines? Finally, it would be nice to add a test case in Lib/test/test_struct.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038854&group_id=5470 From noreply at sourceforge.net Sat Nov 11 14:24:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 05:24:38 -0800 Subject: [Patches] [ python-Patches-841454 ] Cross building python for mingw32 Message-ID: Patches item #841454, was opened at 2003-11-13 15:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841454&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: Cross building python for mingw32 Initial Comment: At first: I can't follow the submission guidelines because I'm sitting behind a firewall and therefore can't access external cvs repositories. So this patch applies to the release Python-2.3.2 source tarball. Nevertheless I hope, it might be useful for others. The attached patch allows to cross-compile python from linux (and probably cygwin) to mingw32. Some remarks: 1) Python's stock configure.in has no support for cross-compilation. Although I've tried to limit the changes to the minimum necessary for a mingw32 build, I'm certain that the changes break some native build anywhere (I've not even tested a single native build seriously). Some (remaining) problems are: - the use of AC_TRY_RUN - looking for /dev/... files at configuration time - the use of 'uname' (instead of configure's --build commandline switch) - ... 2) I'm proposing to use scons for the build of the core extensions for cross-builds (and have included minimal sconstruct/sconscript files) because I do not dare to change distutils to support cross-compilation as I have only finite time resources and I would certainly break all kinds of stock functionality (if I could do it at all). Although scons doesn't support cross-builds either, it at least doesn't prevent them. This way, it seemed easier to me, YMMV. 3) There are quite a few warnings when compiling. I've only halfheartedly tried to solve a few of them. Even when I use vc6 with the warning level pushed to 4 (which should be more compareable to -Wall), many of them don't show up. OTOH, vc6 seems to be more sloppy anyway. Maybe others can help? 4) I have not yet built core extensions with more complex external dependencies and darwin-specific modules (bsddb, tkinter etc., look at Modules/sconscript for a complete (?) list) 5) 'regrtest.py -l -uall' behaves the same for the mingw32-build as for the vc6-build, iff I don't let gcc optimize the code. At least with the default -O3 and also with -O2, test_import.py crashes on the reload test, because the magic number returned by the marshaller is different from the expected 'pyc_magic' in import.c. I've validated that the @test.pyc contains the valid magic number, but the marshaller changes both 0x0a and 0x0d (the most significant word) into '0xff'. This doesn't happen when I give no -O option at all. I've tried to debug this but lost track in import.c:find_module. Whether this is a textmode vs. binarymode issue (I don't believe so) or some overoptimization of gcc or what not, I wasn't able to determine. Perhaps someone more knowledgeable can help out? 6) I've tried to be as close as possible to the vc6 build. So os.name still is 'nt' and sys.platform still is 'win32'. One major difference is, that allmost all extension modules which are builtin by the vc6 build, are external modules in the mingw32 build. This should be ok for most of them, but it is bad for the 'msvcrt' module because most mingw32 people won't be happy to have a second libmsvcrt.a in their libpath. The module should either be always built in, or should be renamed (to '_msvcrt' or something). I'm not sure what is the right thing. I used the following build environment: - autoconf 2.57 - gcc version 3.3.1 (mingw special 20030804-1) - a native python 2.3.2 with scons 0.93 installed Btw: All of those are in debian's 'testing' (or was it 'unstable'?) branch. Attached is the patch. It is so fat, just because I included config.guess and config.sub which are needed by the patched configure script. Although this form only seems to allow one file to be attached, I will try to send in a xbuild-py.sh script, so that you can see, exactly which commandlines you can use. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 14:24 Message: Logged In: YES user_id=21627 Thanks for the patch. Discussion on python-dev indicated that it is, unfortunately, not acceptable, due to its reliance on SCons, so I'm rejecting it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841454&group_id=5470 From noreply at sourceforge.net Sat Nov 11 14:27:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 05:27:38 -0800 Subject: [Patches] [ python-Patches-841461 ] Differentiation between Builtins and extension classes Message-ID: Patches item #841461, was opened at 2003-11-13 15:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841461&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Boris Boutillier (bobox) Assigned to: Nobody/Anonymous (nobody) Summary: Differentiation between Builtins and extension classes Initial Comment: Some checks in the C code are done to avoid modification by the user of builtin classes. Unfortunately this also affects C-extension classes. Since addition of the hackcheck, this is more and more difficult to write a not too obscure workaround for extension classes. Moreover the HeapType flag is used far beyond its original purpose, as described in object.h. The proposed change is to add a new flag, "Modifiable" that indicates if the class can be modified by the python user ( ie if he can set attributes, change classes, change bases). Builtins won't have it, heaptype objects will always have it and extension classes can chose. The flag addition is backward compatible, and binary compatible. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 14:27 Message: Logged In: YES user_id=21627 Can you please give an example of a problem solved by this patch? What is the extension type, what code would the user like to execute, and what error is reported on an attempt to do so? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=841461&group_id=5470 From noreply at sourceforge.net Sat Nov 11 20:58:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 11:58:38 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 21:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Neal Norwitz (nnorwitz) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 19:58 Message: Logged In: YES user_id=849994 * Instead of doing PyObject_CallFunction(dirfunc, "O", obj) you should do PyObject_CallFunctionObjArgs(dirfunc, obj, NULL). * Couldn't __dir__ also be allowed to return a tuple? ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 11:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 05:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 15:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-06 22:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Sat Nov 11 22:31:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 13:31:20 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 23:52 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Neal Norwitz (nnorwitz) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-11 23:31 Message: Logged In: YES user_id=1406776 > PyObject_CallFunctionObjArgs(dirfunc, obj, NULL) done > Couldn't __dir__ also be allowed to return a tuple? no, because tuples are not sortable, and i don't want to over complicate the c-side code of PyObject_Dir. having __dir__ returning only a list is equivalent to __repr__ returning only strings. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 21:58 Message: Logged In: YES user_id=849994 * Instead of doing PyObject_CallFunction(dirfunc, "O", obj) you should do PyObject_CallFunctionObjArgs(dirfunc, obj, NULL). * Couldn't __dir__ also be allowed to return a tuple? ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 13:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 07:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 17:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-07 00:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Sat Nov 11 22:49:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 13:49:08 -0800 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-08-31 22:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-11-11 16:49 Message: Logged In: YES user_id=1344176 I'd be perfectly happy to have the obvious parts applied as soon as possible. I'm hoping to get back to working on Python -- including this patch -- soon; three successive computer failures have thrown a bit of a kink in my free-time coding. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-11-10 19:27 Message: Logged In: YES user_id=764593 Doing the obvious parts first makes sense to me, because it leaves a cleaner slate for comparisons. On the other hand, the job still won't be done, so if Collin wants it all at once, that would be up to him. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 16:25 Message: Logged In: YES user_id=11375 Some bits of this patch (the URL change, using True/False and sys.exc_info()) are uncontroversial. Shall I go ahead and try to apply those bits, or can the debate on the changes converge to a decision? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 18:31 Message: Logged In: YES user_id=764593 (Responding to the patch, not directly to the conversation) (1) (around lines 234) Do you really want two test cases to compare equal because they have the same name, even if that name is the default runTest? (2) Have you made sense of the UnboundMethodType case? As nearly as I can figure, the old behavior was to run call the test case with a method name (which by default tried to run it, using that string as a TestResult?!?, and then returned None), and the new behavior just wraps this None in a TestSuite. (3) After patch, the callable case has a "return test" which is dead code, because the other branches either raised or returned on their own. (4) Changing the raise from ValueError to TypeError would make sense if not for backwards compatibility. Could you use a custom error that inherits from both? Please don't let these comments get you down; this is code that needs cleaning. (The changes to not special-case jython and to not rewalk the mro are particularly good -- because they don't do anything, having them in the code is misleading.) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 17:39 Message: Logged In: YES user_id=1344176 Jim: > (Is there something they could do to the TestCase() that > would start to fail if you wrap it in a TestSuite()? > Remember that they might have local standards saying "only > one test class per file" or something, so they might never > have gotten a real suite back in the past.) Off the top of my head: - TestSuite.run() requires a TestResult instance to be passed in where TestCase.run()'s result parameter is optional. - TestSuite doesn't have TestCase's shortDescription() or id() method. - Assignment to a TestCase instance's failureException attribute will affect the object's run() method, whereas the same assignment on a TestSuite will have no effect. IMHO none of these is significant enough to block that particular section of the patch. Remember that we're talking about a behaviour that's only triggered when the given name resolves to a callable and that callable returns a TestCase instance when invoked. I don't like the idea of keeping around long-standing minor bugs just because someone, somewhere might be using them. Can anyone produce a real example where someone is relying on this behaviour? I'll send a message to c.l.p on Monday and see if anyone in that wider audience can come up with concrete cases where these behaviours are mission-critical. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 17:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 12:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 00:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Sun Nov 12 11:33:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 02:33:13 -0800 Subject: [Patches] [ python-Patches-1065257 ] httplib: allowing stream-type body part in requests Message-ID: Patches item #1065257, was opened at 2004-11-12 16:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Alessandro Forghieri (alien_life_form) Assigned to: Nobody/Anonymous (nobody) Summary: httplib: allowing stream-type body part in requests Initial Comment: Greetings. The attached patch makes it possible to use a file-like object in httplib requests (useful to PUT large files without exhausting the machine memory - think a DAV server). The supplied object must be able to read(). If Content-Length support is desired, the body object must either have a __length__ method (so len(body) works) OR have a stat-able "name" property (file objects are in the second category). Having applied this patch the following works: import httplib import base64 hh={} auth = base64.encodestring("%s:%s" % ("guest","guest")).rstrip() hh['Authorization']='Basic %s' % auth conn=HTTPConnection('localhost',8080) conn.debuglevel=99 thestream=open(r'\tmp\huge.pdf','rb') conn.request('PUT', '/dav/streamed', thestream,hh) thestream.close() rsp=conn.getresponse() print rsp.status,"-",rsp.reason,repr(rsp.msg.dict),rsp.read() conn.close() Opening in 'rb' mode - on windoze - is important for this to work, or the content length header will be wrong, which is probably BAD. Alessandro Forghieri ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 11:33 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed (with modifications) as r52736. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1065257&group_id=5470 From noreply at sourceforge.net Sun Nov 12 11:42:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 02:42:07 -0800 Subject: [Patches] [ python-Patches-1355023 ] support whence argument for GzipFile.seek (bug #1316069) Message-ID: Patches item #1355023, was opened at 2005-11-12 11:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: support whence argument for GzipFile.seek (bug #1316069) Initial Comment: This adds support for whence=0 and whence=1 to the GzipFile seek method. See www.python.org/sf/1316069 for background. Open questions: Q: can/should whence=2 be supported? Q: if not, should whence=2 give an IOError or a ValueError Q: can patches be attached to bug reports? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 11:42 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52737. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 15:33 Message: Logged In: YES user_id=849994 Can this be checked in before 2.5a3? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-13 12:36 Message: Logged In: YES user_id=38376 I'll add a test case and check it in. >From what I can tell, no documentation is affected by this change (maybe the gzip documentation should include a full description of what exactly "simulates most of the methods of a file object" really means, but that's a separate issue). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:57 Message: Logged In: YES user_id=21627 I think whence=2 can be supported, but shouldn't be. For reading, only negative offsets would be meaningful, and they can be supported the same way as they currently are (i.e. read all over). For writing, whence=2 would have no effect. seek apparently always gives a value error (e.g. also file.seek, for whence=10), so it should do so also here. Patches can be attached to bug reports if you are a patch admin. The patch lacks documentation and test case changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1355023&group_id=5470 From noreply at sourceforge.net Sun Nov 12 11:56:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 02:56:08 -0800 Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better handling of float arguments to seek Message-ID: Patches item #1067760, was opened at 2004-11-17 02:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Church (churchr) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1067728: Better handling of float arguments to seek Initial Comment: Instead of converting all float arguments to ints, this first attempts to convert the argument to a PyLong, and then the old conversion code takes over. The upshot is that the limit of floating point arguments to seek() is raised from (2 ** 32) - 1 to somewhere above (2 ** 62). Perhaps a better way to handle this would be to not accept floating point arguments to seek(). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 11:56 Message: Logged In: YES user_id=21627 I'm attaching a different fix, which uses the index API to obtain the offset. As a consequence, passing a float becomes an outright error. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2005-03-29 21:07 Message: Logged In: YES user_id=562624 The actual usable range of a float is 2**53, not 2**62. Above this the resolution drops below 1 byte. It's enough for some 9000 terabytes. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-29 09:00 Message: Logged In: YES user_id=23486 Updated patch to check return value of PyErr_Warn in case 'python -W error' is specified. No other objections raised on python-dev... revised patch still at http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-23 09:29 Message: Logged In: YES user_id=23486 Bob Ippolito pointed out that nowadays float-->int conversion of arguments is deprecated; a DeprecationWarning wasn't being raised because conversion was done manually in seek. Patch to fix this at http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff Linux RH 9.0 works, regression tests run w/o problem. The patch is against the current HEAD but can probably be backported w/ o a problem. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 10:38 Message: Logged In: YES user_id=23486 Sorry, I should add: patch works against head on Linux RH 9.0 (and should work everywhere). Behavior tested with a script. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 10:37 Message: Logged In: YES user_id=23486 The patch works against HEAD; updated for line numbers (there's a very similar set of line elsewhere in the file): http://issola.caltech.edu/~t/transfer/patch-1067760-seek.diff rhettinger thought the current behavior was reasonable (see bug 1067728). I'm not qualified to comment ;) but it seems odd that floats would have drastically different limits than longs. This looks like a reasonable compromise IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470 From noreply at sourceforge.net Sun Nov 12 19:26:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 10:26:20 -0800 Subject: [Patches] [ python-Patches-1067760 ] fix for 1067728: Better handling of float arguments to seek Message-ID: Patches item #1067760, was opened at 2004-11-17 02:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Robert Church (churchr) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 1067728: Better handling of float arguments to seek Initial Comment: Instead of converting all float arguments to ints, this first attempts to convert the argument to a PyLong, and then the old conversion code takes over. The upshot is that the limit of floating point arguments to seek() is raised from (2 ** 32) - 1 to somewhere above (2 ** 62). Perhaps a better way to handle this would be to not accept floating point arguments to seek(). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:26 Message: Logged In: YES user_id=21627 After discussion on python-dev, I committed r52738, which raises a deprecation warning when a float is passed as seek argument; the meaning of doing so remains unchanged. The original patch is thus rejected. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 11:56 Message: Logged In: YES user_id=21627 I'm attaching a different fix, which uses the index API to obtain the offset. As a consequence, passing a float becomes an outright error. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2005-03-29 21:07 Message: Logged In: YES user_id=562624 The actual usable range of a float is 2**53, not 2**62. Above this the resolution drops below 1 byte. It's enough for some 9000 terabytes. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-29 09:00 Message: Logged In: YES user_id=23486 Updated patch to check return value of PyErr_Warn in case 'python -W error' is specified. No other objections raised on python-dev... revised patch still at http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-23 09:29 Message: Logged In: YES user_id=23486 Bob Ippolito pointed out that nowadays float-->int conversion of arguments is deprecated; a DeprecationWarning wasn't being raised because conversion was done manually in seek. Patch to fix this at http://issola.caltech.edu/~t/transfer/patch-1067760-seekwarn.diff Linux RH 9.0 works, regression tests run w/o problem. The patch is against the current HEAD but can probably be backported w/ o a problem. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 10:38 Message: Logged In: YES user_id=23486 Sorry, I should add: patch works against head on Linux RH 9.0 (and should work everywhere). Behavior tested with a script. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 10:37 Message: Logged In: YES user_id=23486 The patch works against HEAD; updated for line numbers (there's a very similar set of line elsewhere in the file): http://issola.caltech.edu/~t/transfer/patch-1067760-seek.diff rhettinger thought the current behavior was reasonable (see bug 1067728). I'm not qualified to comment ;) but it seems odd that floats would have drastically different limits than longs. This looks like a reasonable compromise IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1067760&group_id=5470 From noreply at sourceforge.net Sun Nov 12 19:49:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 10:49:28 -0800 Subject: [Patches] [ python-Patches-1359217 ] ftplib transfer problem with certain servers Message-ID: Patches item #1359217, was opened at 2005-11-17 20:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359217&group_id=5470 Please note that this 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 Private: No Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib transfer problem with certain servers Initial Comment: Gets error_reply exception: 200 Command Ok Some ftp servers return a 2xx response before returning a 1xx response to begin transfer. I don't know whether such servers are in error. The C ftp client (netkit-ftp-0.17) handles this case. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:49 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed (with modificiations) as r52739 and r52740. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2005-11-19 06:45 Message: Logged In: YES user_id=142072 Examples of patch in action, list command: *cmd* 'PASV' *put* 'PASV\r\n' *get* '227 Entering Passive Mode (204,90,130,189,158,118)\r\n' *resp* '227 Entering Passive Mode (204,90,130,189,158,118)' *cmd* 'LIST' *put* 'LIST\r\n' *get* '200 Command Okay.\r\n' *resp* '200 Command Okay.' *get* '150 Opening data connection for transfer.\r\n' *resp* '150 Opening data connection for transfer.' *get* '226-Closing data connection - action successful.\r\n' *get* '\tList command OK, SNRF: 051118183485S0\r\n' *get* '226 \r\n' *resp* '226-Closing data connection - action successful.\n\tList command OK, SNRF: 051118183485S0\n226 ' Store command: *cmd* 'PASV' *put* 'PASV\r\n' *get* '227 Entering Passive Mode (204,90,130,189,138,35)\r\n' *resp* '227 Entering Passive Mode (204,90,130,189,138,35)' *cmd* 'STOR /bms/edi/send/051118.dat' *put* 'STOR /bms/edi/send/051118.dat\r\n' *get* '200 Command Okay.\r\n' *resp* '200 Command Okay.' *get* '150 Opening data connection for transfer.\r\n' *resp* '150 Opening data connection for transfer.' *get* '226-Closing data connection - action successful.\r\n' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359217&group_id=5470 From noreply at sourceforge.net Sun Nov 12 19:51:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 10:51:42 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this 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: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:51 Message: Logged In: YES user_id=21627 What is the status of this patch? Is there any further action necessary? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 23:14 Message: Logged In: YES user_id=89016 Checked in a fix for cStringIO.StringIO.isatty() as r43054. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 18:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 09:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 17:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Sun Nov 12 19:56:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 10:56:52 -0800 Subject: [Patches] [ python-Patches-1360200 ] bdist_rpm still can't handle dashes in versions Message-ID: Patches item #1360200, was opened at 2005-11-18 16:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360200&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: jared jennings (sarynx) Assigned to: Sean Reifschneider (jafo) Summary: bdist_rpm still can't handle dashes in versions Initial Comment: I tried to use Python 2.4.2 to create a bdist_rpm of setuptools, whose version string was 0.6a9dev-r41475. The distutils/command/bdist_rpm module's _make_spec_file method mangled the version to 0.6a9dev_r41475 (line 370). Then when the spec file was being built by rpmbuild, it looked for the sdist named setuptools-0.6a9dev_r41475.tar.gz, which didn't exist: it was called setuptools-0.6a9dev-r41475.tar.gz (note dash). So you have to mangle the version to make rpm happy - but you can't expect the sdist to have the mangled version as part of its name. I looked at the nightly Python source as of 17 Nov 2005 and saw that this bug still exists in the development version of Python. A patch is attached which fixed this bug for me. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:56 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r52741 and r52742 ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2006-09-03 01:25 Message: Logged In: YES user_id=81797 This patch looks good to me. I checked in python-trunk and it still seems to need to be fixed. I'd recommend it gets checked in for the 2.6 release. I'd like one of the distutils people to confirm this though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-21 03:17 Message: Logged In: YES user_id=33168 Sean, you seem to know a lot more about rpms than most of us. Any comment on this approach? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360200&group_id=5470 From noreply at sourceforge.net Mon Nov 13 16:50:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 07:50:34 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-13 16:50 Message: Logged In: YES user_id=89016 truncate() hasn't been changed yet: cStringIO.StringIO.truncate() treats a negative argument as "truncate to the current position". file.truncate() raises a "IOError: [Errno 22] Invalid argument". In this case the StringIO behaviour seems to be the preferable one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:51 Message: Logged In: YES user_id=21627 What is the status of this patch? Is there any further action necessary? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 23:14 Message: Logged In: YES user_id=89016 Checked in a fix for cStringIO.StringIO.isatty() as r43054. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 18:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 09:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 17:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Mon Nov 13 17:46:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 08:46:04 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 00:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 16:46 Message: Logged In: YES user_id=849994 Well, standard C specifies to return EINVAL on negative length. I'm not sure if we should deviate from that behavior as long as files are a quite thin wrapper around standard C files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-13 15:50 Message: Logged In: YES user_id=89016 truncate() hasn't been changed yet: cStringIO.StringIO.truncate() treats a negative argument as "truncate to the current position". file.truncate() raises a "IOError: [Errno 22] Invalid argument". In this case the StringIO behaviour seems to be the preferable one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 18:51 Message: Logged In: YES user_id=21627 What is the status of this patch? Is there any further action necessary? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 22:14 Message: Logged In: YES user_id=89016 Checked in a fix for cStringIO.StringIO.isatty() as r43054. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 17:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 08:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 05:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 16:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Mon Nov 13 18:39:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 09:39:48 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-13 18:39 Message: Logged In: YES user_id=89016 Calling file.truncate() without a argument does a "truncate to current position" so maybe StringIO should raise IOError(EINVAL) on truncate(-1) and both should truncate to the current position on truncate(None)? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 17:46 Message: Logged In: YES user_id=849994 Well, standard C specifies to return EINVAL on negative length. I'm not sure if we should deviate from that behavior as long as files are a quite thin wrapper around standard C files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-13 16:50 Message: Logged In: YES user_id=89016 truncate() hasn't been changed yet: cStringIO.StringIO.truncate() treats a negative argument as "truncate to the current position". file.truncate() raises a "IOError: [Errno 22] Invalid argument". In this case the StringIO behaviour seems to be the preferable one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:51 Message: Logged In: YES user_id=21627 What is the status of this patch? Is there any further action necessary? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 23:14 Message: Logged In: YES user_id=89016 Checked in a fix for cStringIO.StringIO.isatty() as r43054. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 18:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 09:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 17:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Tue Nov 14 00:04:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 15:04:04 -0800 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-19 03:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: Out of Date Priority: 6 Private: No Submitted By: baus (cbaus) >Assigned to: Kristj?n Valur (krisvale) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-11-14 00:04 Message: Logged In: YES user_id=21627 Kristjan, is there anything else to do on this issue? If not, please close as fixed. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-16 19:40 Message: Logged In: YES user_id=21627 typesmodule was already added. Can you please update the subversion, and regenerate the patch adding _socket? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 22:14 Message: Logged In: YES user_id=33168 The patch doesn't apply. I don't have a windows box, so I can't even test it. All I can do is apply. ---------------------------------------------------------------------- Comment By: baus (cbaus) Date: 2006-09-05 22:07 Message: Logged In: YES user_id=1579156 The patch doesn't apply cleanly, or adding this module to the project doesn't apply? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 04:46 Message: Logged In: YES user_id=33168 This patch doesn't apply to 2.5. 2.6 is probably the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Tue Nov 14 00:28:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 15:28:35 -0800 Subject: [Patches] [ python-Patches-846388 ] Check for signals during regular expression matches Message-ID: Patches item #846388, was opened at 2003-11-21 07:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josh Hoyt (joshhoyt) >Assigned to: Fredrik Lundh (effbot) Summary: Check for signals during regular expression matches Initial Comment: This patch adds a call to PyErr_CheckSignals to SRE_MATCH so that signal handlers can be invoked during long regular expression matches. It also adds a new error return value indicating that an exception occurred in a signal handler during the match, allowing exceptions in the signal handler to propagate up to the main loop. Rationale: Regular expressions can run away inside of the C code. There is no way for Python code to stop the C code from running away, so we attempted to use setrlimit to interrupt the process when the CPU usage exceeded a limit. When the signal was received, the signal function was triggered. The sre code does not allow the main loop to run, so the triggered handlers were not called until the regular expression finished, if ever. This behaviour makes the interruption by the signal useless for the purposes of constraining the running time of regular expression matches. I am unsure whether the PyErr_CheckSignals is lightweight enough to be called inside of the for loop in SRE_MATCH, so I took the conservative approach and only checked on recursion or match invocation. I believe that the performance hit from this check would not be prohibitive inside of the loop, since PyErr_CheckSignals does very little work unless there is a signal to handle. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 00:28 Message: Logged In: YES user_id=21627 Fredrik, what do you think about this patch? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-22 16:14 Message: Logged In: YES user_id=21627 Can you give an example for a SRE matching that is so slow that the user may press Ctrl-C? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846388&group_id=5470 From noreply at sourceforge.net Tue Nov 14 17:15:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 08:15:25 -0800 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-19 01:44 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None >Status: Closed Resolution: Out of Date Priority: 6 Private: No Submitted By: baus (cbaus) Assigned to: Kristj?n Valur (krisvale) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- >Comment By: Kristj?n Valur (krisvale) Date: 2006-11-14 16:15 Message: Logged In: YES user_id=1262199 This issue was fixed a while ago. VC8 should link cleanly in both 2.5 and 2.6 trees. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-11-13 23:04 Message: Logged In: YES user_id=21627 Kristjan, is there anything else to do on this issue? If not, please close as fixed. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-09-16 17:40 Message: Logged In: YES user_id=21627 typesmodule was already added. Can you please update the subversion, and regenerate the patch adding _socket? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 20:14 Message: Logged In: YES user_id=33168 The patch doesn't apply. I don't have a windows box, so I can't even test it. All I can do is apply. ---------------------------------------------------------------------- Comment By: baus (cbaus) Date: 2006-09-05 20:07 Message: Logged In: YES user_id=1579156 The patch doesn't apply cleanly, or adding this module to the project doesn't apply? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-05 02:46 Message: Logged In: YES user_id=33168 This patch doesn't apply to 2.5. 2.6 is probably the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Tue Nov 14 19:06:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 10:06:44 -0800 Subject: [Patches] [ python-Patches-1559219 ] Practical ctypes example Message-ID: Patches item #1559219, was opened at 2006-09-15 13:01 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: leppton (leppton) Assigned to: Thomas Heller (theller) Summary: Practical ctypes example Initial Comment: Ctypes module documentation can be little hard to grasp, so I wrote a practical example that reads all function names from dll export directory. It has structures, pointer arithmetic, and function prototype with default parameters. Maybe it fits somewhere in documentation... ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-14 19:06 Message: Logged In: YES user_id=11105 Originator: NO I've added this as a module ctypeslib.contrib.get_exports, in the SVN repository at http://svn.python.org/projects/ctypes/trunk/ctypeslib. Thanks, leppton (if you would like to see your real name in the code somewhere please tell me so). ---------------------------------------------------------------------- Comment By: leppton (leppton) Date: 2006-11-03 01:20 Message: Logged In: YES user_id=1598785 Permission granted for MIT license. Can't help with ELFs, I'm a windows guy :/ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-02 21:41 Message: Logged In: YES user_id=11105 I guess that a ~300 line module is too large to add to the documentation. OTOH, this module implements very useful functionality. If you give me the permission to distribute this module under the MIT license, I would like to add it to a 'ctypeslib' supplemental package (which will also contain other useful stuff). Oh, and the same functionality for ELF-based platforms would be very nice ;-). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559219&group_id=5470 From jheuw at dylian.com.br Thu Nov 16 17:09:39 2006 From: jheuw at dylian.com.br (Betsey Lynch) Date: Thu, 16 Nov 2006 17:09:39 +0100 Subject: [Patches] sunken Message-ID: <455C8D43.7000403@agrico.co.uk> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061116/efb9936e/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: legislator.gif Type: image/gif Size: 13159 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061116/efb9936e/attachment.gif From noreply at sourceforge.net Thu Nov 16 17:57:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 08:57:13 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 16:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Thu Nov 16 22:47:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 13:47:24 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 17:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 22:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Fri Nov 17 01:32:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 16:32:06 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 16:57 Message generated for change (Comment added) made by hanwen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- >Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:32 Message: Logged In: YES user_id=161998 Originator: YES I don't mind, and I expect Jan won't have a problem either. What's the procedure: do we send the disclaimer first, or do you do the review, or does everything happen in parallel? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 21:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Fri Nov 17 01:33:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 16:33:29 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 16:57 Message generated for change (Comment added) made by hanwen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- >Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:33 Message: Logged In: YES user_id=161998 Originator: YES note that not all of the patch needs to go in its current form. In particular, setup.py should be much more clever to look into build-root for finding libs and include files. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:32 Message: Logged In: YES user_id=161998 Originator: YES I don't mind, and I expect Jan won't have a problem either. What's the procedure: do we send the disclaimer first, or do you do the review, or does everything happen in parallel? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 21:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Fri Nov 17 16:44:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 07:44:29 -0800 Subject: [Patches] [ python-Patches-1598415 ] Logging Module - followfile patch Message-ID: Patches item #1598415, was opened at 2006-11-17 09:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 Please note that this 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 Private: No Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 From noreply at sourceforge.net Fri Nov 17 16:56:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 07:56:56 -0800 Subject: [Patches] [ python-Patches-1598426 ] Logging Module - followfile patch Message-ID: Patches item #1598426, was opened at 2006-11-17 09:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598426&group_id=5470 Please note that this 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 Private: No Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598426&group_id=5470 From noreply at sourceforge.net Fri Nov 17 20:46:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 11:46:26 -0800 Subject: [Patches] [ python-Patches-1598426 ] Logging Module - followfile patch Message-ID: Patches item #1598426, was opened at 2006-11-17 15:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598426&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: chads (cjschr) Assigned to: Nobody/Anonymous (nobody) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-17 19:46 Message: Logged In: YES user_id=849994 Originator: NO Duplicate of #1598415. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598426&group_id=5470 From noreply at sourceforge.net Fri Nov 17 20:57:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 11:57:04 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 17:57 Message generated for change (Comment added) made by janneke-sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2006-11-17 20:57 Message: Logged In: YES user_id=1368960 Originator: NO I do not mind either. I've just signed and faxed contrib-form.html. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 01:33 Message: Logged In: YES user_id=161998 Originator: YES note that not all of the patch needs to go in its current form. In particular, setup.py should be much more clever to look into build-root for finding libs and include files. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 01:32 Message: Logged In: YES user_id=161998 Originator: YES I don't mind, and I expect Jan won't have a problem either. What's the procedure: do we send the disclaimer first, or do you do the review, or does everything happen in parallel? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 22:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From ufe at maggots.nl Sat Nov 18 10:14:59 2006 From: ufe at maggots.nl (Ophelia) Date: Fri, 17 Nov 2006 21:14:59 -1200 Subject: [Patches] goodwill Message-ID: <000c01c70af2$a5362160$9b596cc1@lzrnu> Colacchio, president of Dartmouth-Hitchcock Clinic. Billings successfully fought to eliminate the geography department. She wants nothing to do with fighting and has no intentions of. In the meantime, feel free to catch up on what you might've missed: This Week in G-A-Y. His face, the logo of KFC Corp. Those who don't want to commit to a full-time degree can brush up with some short-term intensive study, such as a four-week crash course offered by Dartmouth College's Tuck School of Business. He helps companies figure out how to stop reacting to the past and start creating their own futures through innovation. Formella; and Thomas A. Dubbed "Mobile Manga", these little beauties cost an average of. Meanwhile, Portland still doesn't want to be the "meat in a West Coast man sandwich,". All participants had a history of at least one adenoma in the three months before the start of the study. , has been plastered on the ground near Rachel,. com Geography GuideSite. The news was shared with donors to the medical school and medical center at an earlier event. The report provides valuable information for telecoms, IT and media companies, all of which are being challenged by the convergence that is taking place in this market. This is a Super Easy Deal and you get some neat products just for giving Tupperware a Try! The article below provides an explanation of the disruptive nature of the digital media. And I arrived just in time to catch a very interesting presentation from Gavin Parry from Sony. Formella; and Thomas A. The report is in the new Journal of the National Cancer Institute. Additionally, all finishers and volunteers received a Tucker Nalgene bottle. Saykin: Losing your mind? The Run and Rally is a five-kilometer race in honor of the incoming freshmen, and is held to raise awareness for the Tucker Foundation. She wants nothing to do with fighting and has no intentions of. One of the reasons this report is so popular is that we are one of the few companies that have analysed this very complex market since its inception. She wants nothing to do with fighting and has no intentions of. Those who don't want to commit to a full-time degree can brush up with some short-term intensive study, such as a four-week crash course offered by Dartmouth College's Tuck School of Business. com Geography GuideSite. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061117/63932d6b/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 10751 bytes Desc: not available Url : http://mail.python.org/pipermail/patches/attachments/20061117/63932d6b/attachment-0001.gif From noreply at sourceforge.net Sat Nov 18 19:01:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 10:01:02 -0800 Subject: [Patches] [ python-Patches-1538878 ] tkSimpleDialog.askstring() Tcl/Tk-8.4 lockup Message-ID: Patches item #1538878, was opened at 2006-08-11 20:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538878&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Martin v. L?wis (loewis) Summary: tkSimpleDialog.askstring() Tcl/Tk-8.4 lockup Initial Comment: The following code works ok for Tk-8.3 and earlier but locks up for Tk-8.4: import Tkinter tk = Tkinter.Tk() tk.withdraw() import tkSimpleDialog tkSimpleDialog.askstring("window title", "question?") I Googled and found the explanation and fix from Jeff Epler below. In a nutshell, since the root window is withdrawn, the dialog window "inherits" that property and is not shown either, making it appear that the system has locked up when it is actually waiting for input from an invisible dialog. http://mail.python.org/pipermail/python-list/2005-April/275761.html Tkinter "withdraw" and "askstring" problem Jeff Epler jepler at unpythonic.net Tue Apr 12 15:58:22 CEST 2005 * Previous message: Tkinter "withdraw" and "askstring" problem * Next message: os.open() i flaga lock * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] The answer has to do with a concept Tk calls "transient". wm transient window ?master? If master is specified, then the window manager is informed that window is a transient window (e.g. pull-down menu) working on behalf of master (where master is the path name for a top-level window). If master is specified as an empty string then window is marked as not being a transient window any more. Otherwise the command returns the path name of s current master, or an empty string if window t currently a transient window. A transient window will mirror state changes in the master and inherit the state of the master when initially mapped. It is an error to attempt to make a window a transient of itself. In tkSimpleDialog, the dialog window is unconditionally made transient for the master. Windows is simply following the documentation: The askstring window "inherit[s] the state of the master [i.e., withdrawn] when initially mapped". The fix is to modify tkSimpleDialog.Dialog.__init__ to only make the dialog transient for its master when the master is viewable. This mirrors what is done in dialog.tcl in Tk itself. You can either change tkSimpleDialog.py, or you can include a new definition of __init__ with these lines at the top, and the rest of the function the same: def __init__(self, parent, title = None): ''' the docstring ... ''' Toplevel.__init__(self, parent) if parent.winfo_viewable(): self.transient(parent) ... # Thanks for being so dynamic, Python! tkSimpleDialog.Dialog.__init__ = __init__; del __init__ Jeff ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-18 19:01 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r52780 and r52781 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538878&group_id=5470 From noreply at sourceforge.net Sat Nov 18 19:07:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 10:07:27 -0800 Subject: [Patches] [ python-Patches-1594554 ] tkSimpleDialog freezes when apply raises exception Message-ID: Patches item #1594554, was opened at 2006-11-11 04:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1594554&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: tkSimpleDialog freezes when apply raises exception Initial Comment: Hello. I found attached "a.py" freezes when I clicked "OK" button. (Toplevel widget is no responsible anymore) If this is a bug, is "a.patch" right fix? Thank you. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-18 19:07 Message: Logged In: YES user_id=21627 Originator: NO This looks all fine; thanks for the patch. Committed as r52782 and r52783. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1594554&group_id=5470 From noreply at sourceforge.net Sat Nov 18 19:48:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 10:48:36 -0800 Subject: [Patches] [ python-Patches-1584712 ] Tix: subwidget names (bug #1472877) Message-ID: Patches item #1584712, was opened at 2006-10-25 22:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1584712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Matthias Kievernagel (mkiever) Assigned to: Martin v. L?wis (loewis) Summary: Tix: subwidget names (bug #1472877) Initial Comment: This patch against the trunk rev. 52442 fixes TixSubWidget.__init__ usage of python subwidget names. Now tix subwidget names returned from _subwidget_name are used. See corresponding bug #1472877: http://sourceforge.net/tracker/index.php? func=detail&aid=1472877&group_id=5470&atid=105470 Tested with the code submitted with the bug and with the tix demo code in 'Demo/tix/tixwidgets.py'. Matthias Kievernagel mkiever at web dot de ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-18 19:48 Message: Logged In: YES user_id=21627 Originator: NO I've committed a slightly different patch which merges the len(plist)<2 case into the else case, relying on range(-1)/range(0) to give an empty list. Please review and report any problems you see with it. Committed as r52784 and r52785. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1584712&group_id=5470 From noreply at sourceforge.net Sat Nov 18 20:14:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 11:14:40 -0800 Subject: [Patches] [ python-Patches-1598415 ] Logging Module - followfile patch Message-ID: Patches item #1598415, was opened at 2006-11-17 15:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 Please note that this 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 Private: No Submitted By: chads (cjschr) >Assigned to: Vinay Sajip (vsajip) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-18 19:14 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:21:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:21:19 -0800 Subject: [Patches] [ python-Patches-1586791 ] better error msgs for some TypeErrors Message-ID: Patches item #1586791, was opened at 2006-10-29 19:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 Please note that this 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: Accepted Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: better error msgs for some TypeErrors Initial Comment: This includes the wrong type for some objects' TypeErrors. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:21 Message: Logged In: YES user_id=21627 Originator: NO The patch looks fine to me, please apply. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-08 10:06 Message: Logged In: YES user_id=849994 Thanks, fixed. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-08 09:50 Message: Logged In: YES user_id=89016 The patch includes unrelated changes to enumerate() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:28:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:28:11 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 06:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:28 Message: Logged In: YES user_id=21627 Originator: NO Given that IDLE now has auto-completion, I'm rejecting this patch as out-of-date. jerrykingking, if you would still like to contribute some of it, please submit a new patch. Make sure you address the issues that have been mentioned by the reviewers. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-06-29 18:06 Message: Logged In: YES user_id=1330769 This module is simple and works, but IDLE already has an auto-completion module! It is in Python's SVN and will be part of Python2.5. The module posted here is extremely na?ve and lacking compared to the existing auto-completion module. For example, it catches events instead of the Text widget and inserts characters directly into it to compensate for this. The MultiCall module on which the existing auto-completion module is built it a much better solution. ---------------------------------------------------------------------- Comment By: Jerry (jerrykingking) Date: 2005-11-21 12:28 Message: Logged In: YES user_id=1382613 AutoComplete.py is a IDLE module that extends Listbox and Scrollbar controls with autocompletion capabilities. Although the IDLE provides rich foundation for Python application developers, it doesn't provide any built-in autocompletion support! AutoComplete module fills the gap by bringing autocompletion capabilities to IDLE. Users of IDLE can enjoy the same autocomplete functionality they already know from Pythonwin. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 07:58 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 07:57 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:33:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:33:13 -0800 Subject: [Patches] [ python-Patches-1070218 ] Add BLANK_LINE to token.py Message-ID: Patches item #1070218, was opened at 2004-11-20 22:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Grant Olson (logistix) Assigned to: Jeremy Hylton (jhylton) Summary: Add BLANK_LINE to token.py Initial Comment: The parser module generates an ast node number 54 for an entirely blank line. These lines are apparently ignored by the real parser, and don't have a real definition in include\token.h. Presumably because of that they don't have an entry in token.py. However, this broke an app where I hardcoded the number and recent language features have changed the mapping of numbers to token names. I think there should be a BLANK_LINE defined in token.py so that it can be referred to by name, even if it's not used in the real parser. While dealing with parsermodule generated ast-trees, "symbol.sym_name[node] or token.tok_name[node]" should always be true. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:33 Message: Logged In: YES user_id=21627 Originator: NO As you found yourself, the patch is wrong. This token type is already exposed from tokenize as tokenize.NL; if you use tokenize, you should use its list of token types, not the one of token.py. Closing this patch as rejected. ---------------------------------------------------------------------- Comment By: Grant Olson (logistix) Date: 2004-11-22 01:41 Message: Logged In: YES user_id=699438 A few clarifications: On further review, the node number 54 comes from tokenize.py, not the parsermodule. I also meant to say that "symbol.sym_name.has_key(node) or token.tok_name.has_key(node)" should always be true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070218&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:36:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:36:19 -0800 Subject: [Patches] [ python-Patches-849278 ] improve embeddability of python Message-ID: Patches item #849278, was opened at 2003-11-25 23:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: improve embeddability of python Initial Comment: Add PyInitializeX that omits check in environment variables to set debugging, optimize, and verbose flags. Add PySetSysPaths to specify location of modules and the prefixes and the full path. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:36 Message: Logged In: YES user_id=21627 Originator: NO There hasn't been any update to this patch (e.g contribution of documentation) in two years; rejecting the patch because of lack of feedback. benson_basis, if you ever find the time to work on this again, please submit a new patch. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2004-02-02 03:03 Message: Logged In: YES user_id=876734 The makefile.pre.in change was included here as a mistake. Please ignore it. I'll tackle the documentation as soon as I can. --benson ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-31 13:44 Message: Logged In: YES user_id=21627 Can you please provide patches for the documentation as well? What is the change to Makefile.pre.in? ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-12-11 21:21 Message: Logged In: YES user_id=876734 Here are the Windows patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:41:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:41:21 -0800 Subject: [Patches] [ python-Patches-847857 ] Extend struct.unpack to produce nested tuples Message-ID: Patches item #847857, was opened at 2003-11-23 23:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 Please note that this 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: Out of Date Priority: 5 Private: No Submitted By: Matthew Barnes (mfbarnes) Assigned to: Raymond Hettinger (rhettinger) Summary: Extend struct.unpack to produce nested tuples Initial Comment: This patch extends the struct.unpack format notation to be able to express groups of data with parentheses. For example: >>> data = struct.pack('iiii', 1, 2, 3, 4) >>> struct.unpack('i(ii)i', data) (1, (2, 3), 4) Integral repeat counts can also be applied to groups. >>> struct.unpack('2(ii)', data) ((1, 2), (3, 4)) In addition, struct.calcsize also handles parentheses in format strings correctly. >>> struct.calcsize('4(ii)') 32 No changes were made to struct.pack. It still treats parentheses as illegal format characters. I have not yet updated any documentation or tests associated with struct.calcsize or struct.unpack. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:41 Message: Logged In: YES user_id=21627 Originator: NO This patch is now unfortunately out-of-date, since the struct module was heavily rewritten. Also, the original patch lacked documentation changes, and test cases. mfbarnes, if you are still interested in this feature, please submit a new patch, which hopefully gets reviewed faster this time. Rejecting this patch as out-of-date. ---------------------------------------------------------------------- Comment By: Fabian Bieler (fabe3k) Date: 2005-07-09 19:28 Message: Logged In: YES user_id=615150 I would like to see this patch applied to Python. This functionality would be very usefull for opening binary files with a given format. Is there a particular reason why this patch was not accepted? ---------------------------------------------------------------------- Comment By: Matthew Barnes (mfbarnes) Date: 2004-12-20 07:43 Message: Logged In: YES user_id=843448 I suggested this change on Python-Dev last year (http://mail.python.org/pipermail/python-dev/2003-November/040391.html). The use case I put forth at the time was as follows: Use Case: I have a program written in C that contains a bunch of aggregate data structures (arrays of structs, structs containing arrays, etc.) and I'm transmitting these structures over a socket connection to a Python program that then unpacks the data using the struct module. Problem is that I have to unpack the incoming data as a flat sequence of data elements, and then repartition the sequence into nested sequences to better reflect how the data is structured in the C program. It would be more convenient to express these groupings as I'm unpacking the raw data. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-20 04:57 Message: Logged In: YES user_id=80475 What are the use cases to warrant this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=847857&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:48:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:48:43 -0800 Subject: [Patches] [ python-Patches-1586791 ] better error msgs for some TypeErrors Message-ID: Patches item #1586791, was opened at 2006-10-29 18:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: better error msgs for some TypeErrors Initial Comment: This includes the wrong type for some objects' TypeErrors. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 08:48 Message: Logged In: YES user_id=849994 Originator: YES Checked in as rev. 52787. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 08:21 Message: Logged In: YES user_id=21627 Originator: NO The patch looks fine to me, please apply. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-08 09:06 Message: Logged In: YES user_id=849994 Thanks, fixed. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-08 08:50 Message: Logged In: YES user_id=89016 The patch includes unrelated changes to enumerate() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1586791&group_id=5470 From noreply at sourceforge.net Sun Nov 19 11:23:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 02:23:59 -0800 Subject: [Patches] [ python-Patches-1360243 ] Add XML-RPC Fault Interoperability to XMLRPC libraries Message-ID: Patches item #1360243, was opened at 2005-11-18 17:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360243&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Ginsberg (jaginsberg) Assigned to: Nobody/Anonymous (nobody) Summary: Add XML-RPC Fault Interoperability to XMLRPC libraries Initial Comment: Patched against 2.4.2 SimpleXMLRPCServer.py * Added SimpleXMLRPCDispatcher.register_capability() to manage results for system.getCapabilities() RPC call. * Added SimpleXMLRPCDispatcher.register_fault_interop_spec() to make fault codes compliant with the specification * Abstracted fault code constants. xmlrpclib.py * Added more detailed exception raising for failures in XML-RPC request parsing. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 11:23 Message: Logged In: YES user_id=21627 Originator: NO The patch looks good, however, I have a few questions: - what is the purpose of abstracting fault code constants? For interoperability, I think they should always have the specified values. Furthermore, if register_fault_interop_spec isn't called, it will give 1 as the fault code if some of these faults occurs, which is bad. - why is system.getCapabilities registered in register_fault_interop_spec? That sounds backwards: there should be a register_get_capabilities function, or better yet, this should get registered with register_introspection_functions. - if you agree to these changes so far, I think register_fault_interop_spec should go away, or invoked by default. What is the purpose of making it optional (especially since raising the faults is not optional)? - Please provide documentation changes (i.e. a patch to Doc/lib/libsimplexmlrpc.tex, and Doc/lib/libxmlrpc.tex) - I think ParseError should support "nested" exceptions: the original exception should be included into the ParseError object, in case people want to know the details of the underlying parser error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1360243&group_id=5470 From noreply at sourceforge.net Sun Nov 19 11:45:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 02:45:13 -0800 Subject: [Patches] [ python-Patches-1359365 ] Iterating closed StringIO.StringIO Message-ID: Patches item #1359365, was opened at 2005-11-18 01:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Walter D?rwald (doerwalter) Summary: Iterating closed StringIO.StringIO Initial Comment: This patch changes StringIO.StringIO.next to raise a ValueError when the stream is closed. This is the same behaviour as for cStringIO.StringIO and real files. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 11:45 Message: Logged In: YES user_id=21627 Originator: NO doerwalter: I think it should. StringIO was already behaving that way, so only cStringIO needed to distinguish between -1 and no argument (passing None isn't supported - it isn't for regular files, either). I committed this as r52788, and think that this issue can now be closed. I don't think this change should be backported, as it may break applications, for no good reason. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-13 18:39 Message: Logged In: YES user_id=89016 Calling file.truncate() without a argument does a "truncate to current position" so maybe StringIO should raise IOError(EINVAL) on truncate(-1) and both should truncate to the current position on truncate(None)? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 17:46 Message: Logged In: YES user_id=849994 Well, standard C specifies to return EINVAL on negative length. I'm not sure if we should deviate from that behavior as long as files are a quite thin wrapper around standard C files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-13 16:50 Message: Logged In: YES user_id=89016 truncate() hasn't been changed yet: cStringIO.StringIO.truncate() treats a negative argument as "truncate to the current position". file.truncate() raises a "IOError: [Errno 22] Invalid argument". In this case the StringIO behaviour seems to be the preferable one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 19:51 Message: Logged In: YES user_id=21627 What is the status of this patch? Is there any further action necessary? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 23:14 Message: Logged In: YES user_id=89016 Checked in a fix for cStringIO.StringIO.isatty() as r43054. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 18:37 Message: Logged In: YES user_id=6380 Sure. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-15 09:25 Message: Logged In: YES user_id=89016 Checked in as r43039. What do we do with the other discrepancies. Change cStringIO for both the isatty() and the truncate() problems? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-15 06:31 Message: Logged In: YES user_id=6380 Please check this in if you haven't already done so. I need to shed load! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-29 17:36 Message: Logged In: YES user_id=89016 There are other discrepancies between StringIO.StringIO and cString.StringIO: isatty() raises a ValueError() for a closed StringIO.StringIO and a closed file, but not for a closed cStringIO.StringIO. And the truncate() method when called with a negative argument raised an IOError for StringIO.StringIO and real files, but not for cStringIO.StringIO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1359365&group_id=5470 From noreply at sourceforge.net Sun Nov 19 17:12:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 08:12:28 -0800 Subject: [Patches] [ python-Patches-1599256 ] mailbox.py: check that os.fsync is available before using it Message-ID: Patches item #1599256, was opened at 2006-11-19 16:12 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=1599256&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.py: check that os.fsync is available before using it Initial Comment: I forgot to do this in patch #1514544. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599256&group_id=5470 From noreply at sourceforge.net Sun Nov 19 17:44:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 08:44:29 -0800 Subject: [Patches] [ python-Patches-849407 ] urllib reporthook could be more informative Message-ID: Patches item #849407, was opened at 2003-11-25 22:41 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib reporthook could be more informative Initial Comment: A reporthook in urllib.urlretrieve() (in 2.3.2) is given the max number of characters accepted ("bs") per .read() as its second argument. It would be more helpful to receive the number of characters actually retrieved in the most recent block. While perhaps this would break some existing code (though I can't imagine how), the minor patches below will allow giving progess updates, etc. that are accurate. Thanks Allan Wilson ------------ *** urllib.py.old Tue Nov 25 17:42:55 2003 --- urllib.py Tue Nov 25 18:00:50 2003 *************** *** 236,248 **** reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, bs, size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, bs, size) fp.close() tfp.close() del fp --- 236,248 ---- reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, len(block), size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, len(block), size) fp.close() tfp.close() del fp ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-11-19 11:44 Message: Logged In: YES user_id=6380 Originator: NO I notice that the patch doesn't apply to the svn head (2.6a0). But that's easily fixed and the idea still applies. As the original author of the code being patched I believe my reason for doing it the old way was that I wanted the report hook to be called before the first block, which would let a GUI open up a dialog box before anything was read. The idea was that if the reads are really slow, you'd want the dialog box there right from the start. But this was rather naive, since the most likely source of delay is making the connection and getting the response header back, and the report hook isn't being called at all until all the headers have been seen. The changed API to reporthook() needs to be documented very clearly. There's one call to reporthook() that still passes the block size instead of the actual data size. A naive implementation could be confused by this call, although it is easily recognized because it is the first call and the only one with blocknum equal to zero. I think this is a fine change -- as long as it isn't backported, since it is clearly a feature change. I do wonder "why bother", since most people using urllib don't care all that much about extreme details (I can't remember the last time I specified a reporthook), and most people caring about details don't like urllib and use something else (e.g. httplib, or urllib2). So I guess I'm somewhere between +0 and -0 on this on this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-27 14:41 Message: Logged In: YES user_id=21627 Can you please attach the patch, instead of pasting it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 From noreply at sourceforge.net Sun Nov 19 19:55:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 10:55:20 -0800 Subject: [Patches] [ python-Patches-1070046 ] xmlrpclib - marshalling new-style classes. Message-ID: Patches item #1070046, was opened at 2004-11-20 16:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Gabriel Pastor (gabrielpastor) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib - marshalling new-style classes. Initial Comment: This bug is linked to bug 469972. Tested with python 2.3.4 Bug desciption: Using xmlrpclib today (version 1.0.1) we can marshall old-style classes, but new style classes cannot be marshalled. E.g. import xmlrpclib class NewObject(object): def __init__(self): self.mytype = 'new' class OldObject: def __init__(self): self.mytype = 'old' print xmlrpclib.dumps((OldObject(),)) # result OK, marshalled as a struct print xmlrpclib.dumps((NewObject(),)) # TypeError: cannot marshal # objects So the module doesn't behave in the same way with new-style classes. Bug analysis: The problem is that xmlrpclib try to guess how to marshall an object using the type() method (see line 612), but old-style classes have type 'InstanceType' whereas new-style classes are of type 'ObjectType'. Furthermore as described in bug 469972 we don't know how to marshal class sub-classing builtin types (string, int, etc) Patch proposed: The problem is in the _dump method,. We have this code : try: f = self.dispatch[type(value)] except KeyError: # here goes the patch ! Currently with new-style classes we have a KeyError exception since the ObjectType is not in the key list of self.dispatch. As all objects(string , dict, user defined classes...) in Python now have type 'ObjectType' we cannot just add a line: dispatch[ObjectType] = dump_instance In the KeyError, the patch checks if the object has a dictionnary. Because in this case it is probably a good candidate for being marshalled as a struct. And then the patch checks that the object doesn't inherit from a basic type (int, string etc.. : in fact all the types that are 'normally' marshalled). And if these 2 conditions are OK, this object is marshalled like old-style classes. The proposed patch doesn't change xmlrpclib behaviour for all basic types, and old-style classes since only the 'except KeyError' was changed. Gabriel Pastor ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 19:55 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed (with modifications) as r52790. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1070046&group_id=5470 From noreply at sourceforge.net Sun Nov 19 20:18:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 11:18:03 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 19:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:18 Message: Logged In: YES user_id=21627 Originator: NO The patch is incorrect: without the patch, the scrollbar for the text window ends below the context window. With the patch, the scrollbar is on the side of the context window also. Tentatively rejecting the patch; if you revise it, please add some comments explaining all the computations. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-11-23 10:04 Message: Logged In: YES user_id=1330769 This patch is an improvement for two reasons: 1. One less TK widget is used 2. Replaces literal values with code that fetches the appropriate values from the editor window's widgets I'll admit it's not that big a deal. If it's really a lot of work, I'll leave it up to you to decide whether it's worth it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 02:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Sun Nov 19 21:32:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 12:32:05 -0800 Subject: [Patches] [ python-Patches-1598415 ] Logging Module - followfile patch Message-ID: Patches item #1598415, was opened at 2006-11-17 15:44 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 Please note that this 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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: chads (cjschr) Assigned to: Vinay Sajip (vsajip) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-11-19 20:32 Message: Logged In: YES user_id=308438 Originator: NO This patch, relying as it does on Unix-specific details such as i-nodes, does not appear as if it will work under Windows. For that reason I will mark it as Pending and Invalid for now, if cjschr can update this tracker item with how the patch will work on Windows, I will look at it further. The SF system will automatically close it if no update is made to the item in approx. 2 weeks, though it can still be reopened after that. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-18 19:14 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 From noreply at sourceforge.net Mon Nov 20 00:01:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 15:01:09 -0800 Subject: [Patches] [ python-Patches-1367711 ] Remove usage of UserDict from os.py Message-ID: Patches item #1367711, was opened at 2005-11-27 21:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Remove usage of UserDict from os.py Initial Comment: This patch removes UserDict usage from os.py. It uses the new dict base class instead of UserDict. Patch was generated against Revision 41544 of python subersion repository. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-20 00:01 Message: Logged In: YES user_id=21627 Originator: NO I believe the patch is wrong: it does not support setdefault() (which the current code does). It would be good if there were test cases for os.environ that made sure all dictionary methods had the correct effect on the environment. ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2006-01-16 21:13 Message: Logged In: YES user_id=600792 The intend was to remove dependency on UserDict. Less imports for a minimal python. If there are general problems with the inheritence from dict than they should be documented. I thought in future UserDict will gone. I investigate this problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-29 19:02 Message: Logged In: YES user_id=4771 Subclassing 'dict' to modify some behavior only works more or less in CPython. There are a lot of (admitedly convoluted) ways to get unexpected effects, where the original methods are called instead of the overridden ones. And it's not future-proof: if new methods are added to 'dict' in the future, say a merge() similar to update() but not replacing existing keys, then they will need to be added to that subclass as well, or the method will misbehave. The advantage of UserDict is to guard against all these problems. For example, with the patch: exec "global a; a=5" in os.environ stores the key 'a' directly in os.environ, bypassing the custom __setitem__(). With UserDict instead, we get an explicit error. This is more a joke, but the new-methods-appearing-later problem is more serious IMHO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1367711&group_id=5470 From noreply at sourceforge.net Mon Nov 20 03:30:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 18:30:08 -0800 Subject: [Patches] [ python-Patches-1361016 ] Auto Complete module for IDLE Message-ID: Patches item #1361016, was opened at 2005-11-19 00:40 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Jerry (jerrykingking) Assigned to: Nobody/Anonymous (nobody) Summary: Auto Complete module for IDLE Initial Comment: I think IDLE need this. This is a unattached module. Locate this module on idlelib directory, import it in EditorWindow.py, made it associate with "text" property. OK, it will work. For me it works well. Have a good day, Jerry King ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-11-19 21:30 Message: Logged In: YES user_id=149084 Originator: NO I had left this open because Jerry King's patch has capability that the current implementation lacks. As I recollect, it will autocomplete even if the code has not yet been run. If he could submit a new patch against the current implementation, that would be great. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 03:28 Message: Logged In: YES user_id=21627 Originator: NO Given that IDLE now has auto-completion, I'm rejecting this patch as out-of-date. jerrykingking, if you would still like to contribute some of it, please submit a new patch. Make sure you address the issues that have been mentioned by the reviewers. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-06-29 12:06 Message: Logged In: YES user_id=1330769 This module is simple and works, but IDLE already has an auto-completion module! It is in Python's SVN and will be part of Python2.5. The module posted here is extremely na?ve and lacking compared to the existing auto-completion module. For example, it catches events instead of the Text widget and inserts characters directly into it to compensate for this. The MultiCall module on which the existing auto-completion module is built it a much better solution. ---------------------------------------------------------------------- Comment By: Jerry (jerrykingking) Date: 2005-11-21 06:28 Message: Logged In: YES user_id=1382613 AutoComplete.py is a IDLE module that extends Listbox and Scrollbar controls with autocompletion capabilities. Although the IDLE provides rich foundation for Python application developers, it doesn't provide any built-in autocompletion support! AutoComplete module fills the gap by bringing autocompletion capabilities to IDLE. Users of IDLE can enjoy the same autocomplete functionality they already know from Pythonwin. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 01:58 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-19 01:57 Message: Logged In: YES user_id=149084 The module is undocumented, which isn't acceptable. What functionality does this add to IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1361016&group_id=5470 From noreply at sourceforge.net Mon Nov 20 13:23:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 04:23:54 -0800 Subject: [Patches] [ python-Patches-1584712 ] Tix: subwidget names (bug #1472877) Message-ID: Patches item #1584712, was opened at 2006-10-25 20:32 Message generated for change (Comment added) made by mkiever You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1584712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.6 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Matthias Kievernagel (mkiever) Assigned to: Martin v. L?wis (loewis) Summary: Tix: subwidget names (bug #1472877) Initial Comment: This patch against the trunk rev. 52442 fixes TixSubWidget.__init__ usage of python subwidget names. Now tix subwidget names returned from _subwidget_name are used. See corresponding bug #1472877: http://sourceforge.net/tracker/index.php? func=detail&aid=1472877&group_id=5470&atid=105470 Tested with the code submitted with the bug and with the tix demo code in 'Demo/tix/tixwidgets.py'. Matthias Kievernagel mkiever at web dot de ---------------------------------------------------------------------- >Comment By: Matthias Kievernagel (mkiever) Date: 2006-11-20 12:23 Message: Logged In: YES user_id=1477880 Originator: YES Checked r52795 (current trunk as of 2006-11-20). The bug is gone and Tix demos still work. Looking good. Matthias Kievernagel (mkiever-at-web-dot.de) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-18 18:48 Message: Logged In: YES user_id=21627 Originator: NO I've committed a slightly different patch which merges the len(plist)<2 case into the else case, relying on range(-1)/range(0) to give an empty list. Please review and report any problems you see with it. Committed as r52784 and r52785. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1584712&group_id=5470 From noreply at sourceforge.net Mon Nov 20 18:02:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 09:02:55 -0800 Subject: [Patches] [ python-Patches-1598415 ] Logging Module - followfile patch Message-ID: Patches item #1598415, was opened at 2006-11-17 09:44 Message generated for change (Comment added) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: chads (cjschr) Assigned to: Vinay Sajip (vsajip) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- >Comment By: chads (cjschr) Date: 2006-11-20 11:02 Message: Logged In: YES user_id=1093928 Originator: YES Updated per vsajip to work on Windoze too. The code now checks for a current size < previous size (based on ST_SIZE). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-11-19 14:32 Message: Logged In: YES user_id=308438 Originator: NO This patch, relying as it does on Unix-specific details such as i-nodes, does not appear as if it will work under Windows. For that reason I will mark it as Pending and Invalid for now, if cjschr can update this tracker item with how the patch will work on Windows, I will look at it further. The SF system will automatically close it if no update is made to the item in approx. 2 weeks, though it can still be reopened after that. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-18 13:14 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 From noreply at sourceforge.net Mon Nov 20 18:06:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 09:06:12 -0800 Subject: [Patches] [ python-Patches-1598415 ] Logging Module - followfile patch Message-ID: Patches item #1598415, was opened at 2006-11-17 09:44 Message generated for change (Comment added) made by cjschr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: chads (cjschr) Assigned to: Vinay Sajip (vsajip) Summary: Logging Module - followfile patch Initial Comment: Pertaining to the FileHandler and the file being written to: It's possible that the file being written to will be rolled-over by an external application such as newsyslog. By default, FileHandler tracks the file descriptor, not the file. If the original file is renamed, the file descriptor is still updated; however, it's probably desired that continued updates to the original file take place instead. This patch adds an attribute to the FileHandler class constructor (and basicConfig kw as well). If the attribute evaluates to True, the filename, not the descriptor is tracked. Basically, the code compares the file status from a previous emit call to the current call before the base class emit is called. If a difference in st_ino or st_dev is found, the current stream is flush/closed and a new one, based on baseFilename, is created, file status is updated, and then the base class emit is called. ---------------------------------------------------------------------- >Comment By: chads (cjschr) Date: 2006-11-20 11:06 Message: Logged In: YES user_id=1093928 Originator: YES Uploaded the wrong diff. This is the correct one. ---------------------------------------------------------------------- Comment By: chads (cjschr) Date: 2006-11-20 11:02 Message: Logged In: YES user_id=1093928 Originator: YES Updated per vsajip to work on Windoze too. The code now checks for a current size < previous size (based on ST_SIZE). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-11-19 14:32 Message: Logged In: YES user_id=308438 Originator: NO This patch, relying as it does on Unix-specific details such as i-nodes, does not appear as if it will work under Windows. For that reason I will mark it as Pending and Invalid for now, if cjschr can update this tracker item with how the patch will work on Windows, I will look at it further. The SF system will automatically close it if no update is made to the item in approx. 2 weeks, though it can still be reopened after that. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-18 13:14 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Vinay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1598415&group_id=5470 From noreply at sourceforge.net Mon Nov 20 18:15:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 09:15:59 -0800 Subject: [Patches] [ python-Patches-1599845 ] TCPServer option to bind and activate Message-ID: Patches item #1599845, was opened at 2006-11-20 12:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: TCPServer option to bind and activate Initial Comment: Adds a flag to the TCPServer constructor to automatically call server_bind and server_activate or not. Setting this flag to False gives the programmer the chance to manipulate allow_reuse_address on the instance without having to subclass TCPServer or its derivatives just to change the flag. Adds this flag to SimpleXMLRPCServer.__init__ also. See bug #1595742. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 From noreply at sourceforge.net Mon Nov 20 20:06:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 11:06:18 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 20:06 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Open Resolution: Rejected Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2006-11-20 21:06 Message: Logged In: YES user_id=1330769 Originator: YES Seems like a bug in EditorWindow.py to me - shouldn't edtiwin.vbar (the scrollbar) be created inside editwin.text_frame instead of editwin.top? Seems to me that this is the reason text_frame is there in the first place - to encapsulate the Text widget and the scrollbar that accompanies it. Funny that I hadn't noticed the odd placement of the scrollbar... Thanks for the thorough review! I've submitted a revised patch, which fixes the bug in EditorWindow.py. I've also wrapped all widget attribute lookups in try/except blocks to avoid weird Tk behavior. This way future changes in Tk's inner workings will cause the text to be misaligned, instead of crashing IDLE. Lastly, I've added verbose comments where appropriate. Testing on current SVN trunk version of IDLE with only these changes shows no problems, and it works smoothly with my development version of IDLE as well. Let's finally get this piece of code behind us :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 21:18 Message: Logged In: YES user_id=21627 Originator: NO The patch is incorrect: without the patch, the scrollbar for the text window ends below the context window. With the patch, the scrollbar is on the side of the context window also. Tentatively rejecting the patch; if you revise it, please add some comments explaining all the computations. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-11-23 11:04 Message: Logged In: YES user_id=1330769 This patch is an improvement for two reasons: 1. One less TK widget is used 2. Replaces literal values with code that fetches the appropriate values from the editor window's widgets I'll admit it's not that big a deal. If it's really a lot of work, I'll leave it up to you to decide whether it's worth it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 03:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Mon Nov 20 20:33:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 11:33:31 -0800 Subject: [Patches] [ python-Patches-1540874 ] broken shortcut keys Message-ID: Patches item #1540874, was opened at 2006-08-15 22:29 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: broken shortcut keys Initial Comment: Idle menu entries can include a "_" indicating to use that character for a keyboard shortcut. Because Typing the key actually runs the shortcut (instead of just moving along the menu), there is no way to use the same shortcut on more than one entry -- listing it just misleads people into accidentally requesting the wrong command. Unfortunately, the default configuration does this for the File menu. It claims that Alt-f-p will save a copy as and print, but it actually just opens a path browser. This change (1) Uses the y key for save Cop_y (2) Stops pretending to have a key for print. I'll trust someone else's judgement on whether this is a bugfix (the advertised shortcuts don't work) or a feature (particularly the new binding for copy). ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 21:33 Message: Logged In: YES user_id=1330769 Originator: NO I actually prefer to not have a key for the "Print" item, since accidentally choosing it will print all of the code in the current window. On the same note, I think the default keybinding for the "Print" command shouldn't be Ctrl+P as it is now, for the same reason stated above. I prefer to have no key binding for it, since it isn't such a commonplace command, and invoking it accidentally is a major annoyance. However, currently IDLE assumes that every key in the keybindigs list must have a keybinding. If we don't want to change this, or if we insist on having a default keybinding for "Print", let's choose a combination that is less likely to be pressed accidentaly. (perhaps Ctrl+Alt+P) I could easily write a patch for this, just want to ask what you think should be done. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-17 00:48 Message: Logged In: YES user_id=149084 I chose 'T' for Print. Also modified the Shell menu hotkey, it's now 'L'. Rev 51329 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 22:57 Message: Logged In: YES user_id=764593 Changing priority to 7 because I consider it a bug, but am reluctant to push GUI changes after release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 From noreply at sourceforge.net Tue Nov 21 03:55:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 18:55:34 -0800 Subject: [Patches] [ python-Patches-1540874 ] broken shortcut keys Message-ID: Patches item #1540874, was opened at 2006-08-15 15:29 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: broken shortcut keys Initial Comment: Idle menu entries can include a "_" indicating to use that character for a keyboard shortcut. Because Typing the key actually runs the shortcut (instead of just moving along the menu), there is no way to use the same shortcut on more than one entry -- listing it just misleads people into accidentally requesting the wrong command. Unfortunately, the default configuration does this for the File menu. It claims that Alt-f-p will save a copy as and print, but it actually just opens a path browser. This change (1) Uses the y key for save Cop_y (2) Stops pretending to have a key for print. I'll trust someone else's judgement on whether this is a bugfix (the advertised shortcuts don't work) or a feature (particularly the new binding for copy). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-11-20 21:55 Message: Logged In: YES user_id=149084 Originator: NO Ctrl-P is the standard binding for Print on Windows. If you don't like it, assign it to some other key using your Options dialog. I don't want a patch, thanks anyway! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 14:33 Message: Logged In: YES user_id=1330769 Originator: NO I actually prefer to not have a key for the "Print" item, since accidentally choosing it will print all of the code in the current window. On the same note, I think the default keybinding for the "Print" command shouldn't be Ctrl+P as it is now, for the same reason stated above. I prefer to have no key binding for it, since it isn't such a commonplace command, and invoking it accidentally is a major annoyance. However, currently IDLE assumes that every key in the keybindigs list must have a keybinding. If we don't want to change this, or if we insist on having a default keybinding for "Print", let's choose a combination that is less likely to be pressed accidentaly. (perhaps Ctrl+Alt+P) I could easily write a patch for this, just want to ask what you think should be done. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 17:48 Message: Logged In: YES user_id=149084 I chose 'T' for Print. Also modified the Shell menu hotkey, it's now 'L'. Rev 51329 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:57 Message: Logged In: YES user_id=764593 Changing priority to 7 because I consider it a bug, but am reluctant to push GUI changes after release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 From noreply at sourceforge.net Tue Nov 21 03:56:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 18:56:35 -0800 Subject: [Patches] [ python-Patches-1540874 ] broken shortcut keys Message-ID: Patches item #1540874, was opened at 2006-08-15 15:29 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: broken shortcut keys Initial Comment: Idle menu entries can include a "_" indicating to use that character for a keyboard shortcut. Because Typing the key actually runs the shortcut (instead of just moving along the menu), there is no way to use the same shortcut on more than one entry -- listing it just misleads people into accidentally requesting the wrong command. Unfortunately, the default configuration does this for the File menu. It claims that Alt-f-p will save a copy as and print, but it actually just opens a path browser. This change (1) Uses the y key for save Cop_y (2) Stops pretending to have a key for print. I'll trust someone else's judgement on whether this is a bugfix (the advertised shortcuts don't work) or a feature (particularly the new binding for copy). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-11-20 21:56 Message: Logged In: YES user_id=149084 Originator: NO Ctrl-P is the standard binding for Print on Windows. If you don't like it, assign it to some other key using your Options dialog. I don't want a patch, thanks anyway! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-11-20 21:55 Message: Logged In: YES user_id=149084 Originator: NO Ctrl-P is the standard binding for Print on Windows. If you don't like it, assign it to some other key using your Options dialog. I don't want a patch, thanks anyway! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 14:33 Message: Logged In: YES user_id=1330769 Originator: NO I actually prefer to not have a key for the "Print" item, since accidentally choosing it will print all of the code in the current window. On the same note, I think the default keybinding for the "Print" command shouldn't be Ctrl+P as it is now, for the same reason stated above. I prefer to have no key binding for it, since it isn't such a commonplace command, and invoking it accidentally is a major annoyance. However, currently IDLE assumes that every key in the keybindigs list must have a keybinding. If we don't want to change this, or if we insist on having a default keybinding for "Print", let's choose a combination that is less likely to be pressed accidentaly. (perhaps Ctrl+Alt+P) I could easily write a patch for this, just want to ask what you think should be done. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 17:48 Message: Logged In: YES user_id=149084 I chose 'T' for Print. Also modified the Shell menu hotkey, it's now 'L'. Rev 51329 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:57 Message: Logged In: YES user_id=764593 Changing priority to 7 because I consider it a bug, but am reluctant to push GUI changes after release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 From noreply at sourceforge.net Tue Nov 21 04:11:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 19:11:23 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 13:06 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Rejected >Priority: 3 Private: No Submitted By: Tal Einat (taleinat) >Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 14:06 Message: Logged In: YES user_id=1330769 Originator: YES Seems like a bug in EditorWindow.py to me - shouldn't edtiwin.vbar (the scrollbar) be created inside editwin.text_frame instead of editwin.top? Seems to me that this is the reason text_frame is there in the first place - to encapsulate the Text widget and the scrollbar that accompanies it. Funny that I hadn't noticed the odd placement of the scrollbar... Thanks for the thorough review! I've submitted a revised patch, which fixes the bug in EditorWindow.py. I've also wrapped all widget attribute lookups in try/except blocks to avoid weird Tk behavior. This way future changes in Tk's inner workings will cause the text to be misaligned, instead of crashing IDLE. Lastly, I've added verbose comments where appropriate. Testing on current SVN trunk version of IDLE with only these changes shows no problems, and it works smoothly with my development version of IDLE as well. Let's finally get this piece of code behind us :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 14:18 Message: Logged In: YES user_id=21627 Originator: NO The patch is incorrect: without the patch, the scrollbar for the text window ends below the context window. With the patch, the scrollbar is on the side of the context window also. Tentatively rejecting the patch; if you revise it, please add some comments explaining all the computations. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-11-23 04:04 Message: Logged In: YES user_id=1330769 This patch is an improvement for two reasons: 1. One less TK widget is used 2. Replaces literal values with code that fetches the appropriate values from the editor window's widgets I'll admit it's not that big a deal. If it's really a lot of work, I'll leave it up to you to decide whether it's worth it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-22 20:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Tue Nov 21 12:57:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 03:57:30 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 13:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Tue Nov 21 15:49:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 06:49:11 -0800 Subject: [Patches] [ python-Patches-1540874 ] broken shortcut keys Message-ID: Patches item #1540874, was opened at 2006-08-15 22:29 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: broken shortcut keys Initial Comment: Idle menu entries can include a "_" indicating to use that character for a keyboard shortcut. Because Typing the key actually runs the shortcut (instead of just moving along the menu), there is no way to use the same shortcut on more than one entry -- listing it just misleads people into accidentally requesting the wrong command. Unfortunately, the default configuration does this for the File menu. It claims that Alt-f-p will save a copy as and print, but it actually just opens a path browser. This change (1) Uses the y key for save Cop_y (2) Stops pretending to have a key for print. I'll trust someone else's judgement on whether this is a bugfix (the advertised shortcuts don't work) or a feature (particularly the new binding for copy). ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-21 16:49 Message: Logged In: YES user_id=1330769 Originator: NO Perhaps Ctrl+P is the standard keybinding for printing on Windows, but the windows standard is that the print command opens a print dialog. Therefore, is you invoked the command by mistake, you just hit "cancel" in the dialog. However this isn't the case in IDLE - IDLE just prints all of the text in the window. I've personally been bitten by this and several others, since we didn't know that Ctrl+P just sent the entire text to be printed. IDLE doesn't even notify you that you've sent the data for printing, so sometimes this is realized only after the entire thing has been printed. So if it's sticking to the standards we want, we should have IDLE pop up a "print..." dialog on Windows. (shouldn't be too hard with win32, is it possible without it?) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-11-21 04:56 Message: Logged In: YES user_id=149084 Originator: NO Ctrl-P is the standard binding for Print on Windows. If you don't like it, assign it to some other key using your Options dialog. I don't want a patch, thanks anyway! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-11-21 04:55 Message: Logged In: YES user_id=149084 Originator: NO Ctrl-P is the standard binding for Print on Windows. If you don't like it, assign it to some other key using your Options dialog. I don't want a patch, thanks anyway! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 21:33 Message: Logged In: YES user_id=1330769 Originator: NO I actually prefer to not have a key for the "Print" item, since accidentally choosing it will print all of the code in the current window. On the same note, I think the default keybinding for the "Print" command shouldn't be Ctrl+P as it is now, for the same reason stated above. I prefer to have no key binding for it, since it isn't such a commonplace command, and invoking it accidentally is a major annoyance. However, currently IDLE assumes that every key in the keybindigs list must have a keybinding. If we don't want to change this, or if we insist on having a default keybinding for "Print", let's choose a combination that is less likely to be pressed accidentaly. (perhaps Ctrl+Alt+P) I could easily write a patch for this, just want to ask what you think should be done. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-17 00:48 Message: Logged In: YES user_id=149084 I chose 'T' for Print. Also modified the Shell menu hotkey, it's now 'L'. Rev 51329 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 22:57 Message: Logged In: YES user_id=764593 Changing priority to 7 because I consider it a bug, but am reluctant to push GUI changes after release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 From noreply at sourceforge.net Tue Nov 21 16:38:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 07:38:48 -0800 Subject: [Patches] [ python-Patches-1600491 ] 1572210 doc patch Message-ID: Patches item #1600491, was opened at 2006-11-21 10:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600491&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 1572210 doc patch Initial Comment: help on a keyword doesn't work, unless the help files are built. On at least windows, they are not built by default. This adds instructions on how to build them. C:\Python25\Doc>hh -decompile . Python25.chm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600491&group_id=5470 From noreply at sourceforge.net Tue Nov 21 19:28:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 10:28:33 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 13:57 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-21 20:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Tue Nov 21 19:29:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 10:29:44 -0800 Subject: [Patches] [ python-Patches-849407 ] urllib reporthook could be more informative Message-ID: Patches item #849407, was opened at 2003-11-26 04:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib reporthook could be more informative Initial Comment: A reporthook in urllib.urlretrieve() (in 2.3.2) is given the max number of characters accepted ("bs") per .read() as its second argument. It would be more helpful to receive the number of characters actually retrieved in the most recent block. While perhaps this would break some existing code (though I can't imagine how), the minor patches below will allow giving progess updates, etc. that are accurate. Thanks Allan Wilson ------------ *** urllib.py.old Tue Nov 25 17:42:55 2003 --- urllib.py Tue Nov 25 18:00:50 2003 *************** *** 236,248 **** reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, bs, size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, bs, size) fp.close() tfp.close() del fp --- 236,248 ---- reporthook(0, bs, size) block = fp.read(bs) if reporthook: ! reporthook(1, len(block), size) while block: tfp.write(block) block = fp.read(bs) blocknum = blocknum + 1 if reporthook: ! reporthook(blocknum, len(block), size) fp.close() tfp.close() del fp ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-21 19:29 Message: Logged In: YES user_id=21627 Originator: NO Discussion on python-dev revealed that read() on a socket will always give you blocksize data, except for the last block. So this doesn't really change anything in practice; applications that find that the data read (blocksize*blocknumber) exceeds the amount of data expected should conclude that they saw the last block. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-11-19 17:44 Message: Logged In: YES user_id=6380 Originator: NO I notice that the patch doesn't apply to the svn head (2.6a0). But that's easily fixed and the idea still applies. As the original author of the code being patched I believe my reason for doing it the old way was that I wanted the report hook to be called before the first block, which would let a GUI open up a dialog box before anything was read. The idea was that if the reads are really slow, you'd want the dialog box there right from the start. But this was rather naive, since the most likely source of delay is making the connection and getting the response header back, and the report hook isn't being called at all until all the headers have been seen. The changed API to reporthook() needs to be documented very clearly. There's one call to reporthook() that still passes the block size instead of the actual data size. A naive implementation could be confused by this call, although it is easily recognized because it is the first call and the only one with blocknum equal to zero. I think this is a fine change -- as long as it isn't backported, since it is clearly a feature change. I do wonder "why bother", since most people using urllib don't care all that much about extreme details (I can't remember the last time I specified a reporthook), and most people caring about details don't like urllib and use something else (e.g. httplib, or urllib2). So I guess I'm somewhere between +0 and -0 on this on this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-27 20:41 Message: Logged In: YES user_id=21627 Can you please attach the patch, instead of pasting it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849407&group_id=5470 From noreply at sourceforge.net Tue Nov 21 22:33:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 13:33:54 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 13:57 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-21 23:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 20:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Wed Nov 22 03:44:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 18:44:00 -0800 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-11-22 11:44 Message: Logged In: YES user_id=595483 Originator: YES Now the compiler package works. The patch passes regrtest with "-u all" option and "-u compiler" option (except test_frozen.py). The patch is against latest p3yk branch HEAD. The last patch accidentally included some test code in test_compiler.py (and which is committed to the svn) so this patch includes fix for that. Ah, Guido, when you committed the patch (previous version) last time, you did not add Lib/test/test_keywordonlyarg.py so, this time, don't forget to add it :) Also, last time when we talked, I think you said that the patch makes some test case fail on your laptop machine. You might want to check that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-10-28 08:32 Message: Logged In: YES user_id=6380 Checked in as r52491. I'm keeping this open awaiting a patch for the compiler package. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-10-10 07:22 Message: Logged In: YES user_id=595483 The new patch that I am uploading fixes the Grammar problem - originally I made mistake not allowing *vararg after keyword only argument. The python compiler package doesn't work now, but everything else should work now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-16 02:13 Message: Logged In: YES user_id=6380 I see. The Grammar should simply make the NAME after the '*' optional. Shouldn't be too hard to fix should it? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 16:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 06:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-12 04:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-08 02:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 14:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Wed Nov 22 05:56:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 20:56:53 -0800 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-30 21:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-11-21 23:56 Message: Logged In: YES user_id=6380 Originator: NO Submitted. Jiwon, can you mail me another copy of test_keywordinoyarg.py? I believe I lost it. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-11-21 21:44 Message: Logged In: YES user_id=595483 Originator: YES Now the compiler package works. The patch passes regrtest with "-u all" option and "-u compiler" option (except test_frozen.py). The patch is against latest p3yk branch HEAD. The last patch accidentally included some test code in test_compiler.py (and which is committed to the svn) so this patch includes fix for that. Ah, Guido, when you committed the patch (previous version) last time, you did not add Lib/test/test_keywordonlyarg.py so, this time, don't forget to add it :) Also, last time when we talked, I think you said that the patch makes some test case fail on your laptop machine. You might want to check that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-10-27 19:32 Message: Logged In: YES user_id=6380 Checked in as r52491. I'm keeping this open awaiting a patch for the compiler package. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-10-09 18:22 Message: Logged In: YES user_id=595483 The new patch that I am uploading fixes the Grammar problem - originally I made mistake not allowing *vararg after keyword only argument. The python compiler package doesn't work now, but everything else should work now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-15 13:13 Message: Logged In: YES user_id=6380 I see. The Grammar should simply make the NAME after the '*' optional. Shouldn't be too hard to fix should it? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 03:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-13 17:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-11 15:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-07 13:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 01:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Wed Nov 22 07:50:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 22:50:05 -0800 Subject: [Patches] [ python-Patches-1599845 ] TCPServer option to bind and activate Message-ID: Patches item #1599845, was opened at 2006-11-20 18:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: TCPServer option to bind and activate Initial Comment: Adds a flag to the TCPServer constructor to automatically call server_bind and server_activate or not. Setting this flag to False gives the programmer the chance to manipulate allow_reuse_address on the instance without having to subclass TCPServer or its derivatives just to change the flag. Adds this flag to SimpleXMLRPCServer.__init__ also. See bug #1595742. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 07:50 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide documentation patches as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 From noreply at sourceforge.net Wed Nov 22 09:51:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 00:51:17 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 19:06 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 3 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 09:51 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. I can't find anything wrong anymore, and agree that the restructuring is better, so I have committed it as r52821. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 20:06 Message: Logged In: YES user_id=1330769 Originator: YES Seems like a bug in EditorWindow.py to me - shouldn't edtiwin.vbar (the scrollbar) be created inside editwin.text_frame instead of editwin.top? Seems to me that this is the reason text_frame is there in the first place - to encapsulate the Text widget and the scrollbar that accompanies it. Funny that I hadn't noticed the odd placement of the scrollbar... Thanks for the thorough review! I've submitted a revised patch, which fixes the bug in EditorWindow.py. I've also wrapped all widget attribute lookups in try/except blocks to avoid weird Tk behavior. This way future changes in Tk's inner workings will cause the text to be misaligned, instead of crashing IDLE. Lastly, I've added verbose comments where appropriate. Testing on current SVN trunk version of IDLE with only these changes shows no problems, and it works smoothly with my development version of IDLE as well. Let's finally get this piece of code behind us :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:18 Message: Logged In: YES user_id=21627 Originator: NO The patch is incorrect: without the patch, the scrollbar for the text window ends below the context window. With the patch, the scrollbar is on the side of the context window also. Tentatively rejecting the patch; if you revise it, please add some comments explaining all the computations. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-11-23 10:04 Message: Logged In: YES user_id=1330769 This patch is an improvement for two reasons: 1. One less TK widget is used 2. Replaces literal values with code that fetches the appropriate values from the editor window's widgets I'll admit it's not that big a deal. If it's really a lot of work, I'll leave it up to you to decide whether it's worth it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 02:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From noreply at sourceforge.net Wed Nov 22 09:58:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 00:58:31 -0800 Subject: [Patches] [ python-Patches-1076826 ] readline does not need termcap Message-ID: Patches item #1076826, was opened at 2004-12-01 16:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Michal ?iha? (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: readline does not need termcap Initial Comment: Readline doesn't need -ltermcap (at least on some systems), so configure check should deal with this. Attached patch completely removes -ltermcap, however better might be to check both possibilities. Patch is against 2.3.3, however it applies to 2.4 also. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 09:58 Message: Logged In: YES user_id=21627 Originator: NO I think this patch is obsolete since r41945; closing it as out-of-date. ---------------------------------------------------------------------- Comment By: Michal ?iha? (nijel) Date: 2004-12-06 23:48 Message: Logged In: YES user_id=192186 Ooops, I should better read what I write, there shouldn't be twice ncurses, once it should be termcap.... Sorry. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 23:29 Message: Logged In: YES user_id=21627 This patch is still incorrect. It breaks on systems where readline requires termcap, e.g. Solaris. ---------------------------------------------------------------------- Comment By: Michal ?iha? (nijel) Date: 2004-12-06 12:18 Message: Logged In: YES user_id=192186 Okay, here is IMHO correct patch, which does more or less same as setup.py does for finding needed libraries. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 19:59 Message: Logged In: YES user_id=21627 The patch is incorrect. As you suggest yourself, readline *does* need -ltermcap on some systems; this patch breaks these systems. Rejecting the patch. If you can come up with a patch that performs an autoconf test first, please submit a new patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1076826&group_id=5470 From noreply at sourceforge.net Wed Nov 22 10:03:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 01:03:06 -0800 Subject: [Patches] [ python-Patches-1079729 ] Make cgi.py use logging module Message-ID: Patches item #1079729, was opened at 2004-12-06 05:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079729&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Josh Hoyt (joshhoyt) Assigned to: Nobody/Anonymous (nobody) Summary: Make cgi.py use logging module Initial Comment: The attached patch makes the CGI module use the logging module for logging. There is no change in behaviour for the old idioms of using the cgi module's built-in logging facility, but this allows users to use the logging framework to direct and format log messages. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 10:03 Message: Logged In: YES user_id=21627 Originator: NO It appears the submitter hasn't taken the proposed steps. Rejecting the patch for lack of feedback. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 03:04 Message: Logged In: YES user_id=469548 You might want to follow the proposal in PEP 337 (create a cgi._log, use py. prefix). Of course, you could also disagree with the PEP, in which case you should take it up on python-dev ;). Either way, please assign this to me once you've got a PEP behind you and I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1079729&group_id=5470 From noreply at sourceforge.net Wed Nov 22 15:30:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 06:30:04 -0800 Subject: [Patches] [ python-Patches-1362975 ] CodeContext - Improved text indentation Message-ID: Patches item #1362975, was opened at 2005-11-21 20:06 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Closed Resolution: Accepted Priority: 3 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - Improved text indentation Initial Comment: This is a second patch for the text indentation - the first one was sent by mail and patched directly by KBK. I've touched up the indentation code to be cleaner and more generic. There's no longer need for a pad Frame, the padding is done by the Label widget. More IDLE patches coming - stay tuned ;) ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2006-11-22 16:30 Message: Logged In: YES user_id=1330769 Originator: YES Woohoo! :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 10:51 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. I can't find anything wrong anymore, and agree that the restructuring is better, so I have committed it as r52821. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-11-20 21:06 Message: Logged In: YES user_id=1330769 Originator: YES Seems like a bug in EditorWindow.py to me - shouldn't edtiwin.vbar (the scrollbar) be created inside editwin.text_frame instead of editwin.top? Seems to me that this is the reason text_frame is there in the first place - to encapsulate the Text widget and the scrollbar that accompanies it. Funny that I hadn't noticed the odd placement of the scrollbar... Thanks for the thorough review! I've submitted a revised patch, which fixes the bug in EditorWindow.py. I've also wrapped all widget attribute lookups in try/except blocks to avoid weird Tk behavior. This way future changes in Tk's inner workings will cause the text to be misaligned, instead of crashing IDLE. Lastly, I've added verbose comments where appropriate. Testing on current SVN trunk version of IDLE with only these changes shows no problems, and it works smoothly with my development version of IDLE as well. Let's finally get this piece of code behind us :) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 21:18 Message: Logged In: YES user_id=21627 Originator: NO The patch is incorrect: without the patch, the scrollbar for the text window ends below the context window. With the patch, the scrollbar is on the side of the context window also. Tentatively rejecting the patch; if you revise it, please add some comments explaining all the computations. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2005-11-23 11:04 Message: Logged In: YES user_id=1330769 This patch is an improvement for two reasons: 1. One less TK widget is used 2. Replaces literal values with code that fetches the appropriate values from the editor window's widgets I'll admit it's not that big a deal. If it's really a lot of work, I'll leave it up to you to decide whether it's worth it. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-23 03:25 Message: Logged In: YES user_id=149084 At first glance the new code seems harder to understand and is longer. What is the advantage of going through the effort to apply, test, check in, and properly document the change? p.s. use Expand=False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1362975&group_id=5470 From greetings at webmail.2000Greetings.com Wed Nov 22 16:39:42 2006 From: greetings at webmail.2000Greetings.com (2000Greetings.com) Date: Wed, 22 Nov 2006 16:39:42 +0100 (CET) Subject: [Patches] you have received a 2000Greetings Card... Message-ID: <20061122153942.807CA833132@p15139065.pureserver.info> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20061122/6b131cc5/attachment.htm From noreply at sourceforge.net Wed Nov 22 19:55:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 10:55:13 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 12:57 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 19:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 22:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 19:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Wed Nov 22 20:58:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 11:58:55 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 06:57 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 14:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 13:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 16:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 13:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Wed Nov 22 21:07:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 12:07:58 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 13:57 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-22 22:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 21:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 20:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 23:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 20:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Wed Nov 22 21:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 12:30:48 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 06:57 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 15:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 14:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 13:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 16:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 13:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Wed Nov 22 21:43:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 12:43:24 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 13:57 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-22 22:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 22:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 22:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 21:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 20:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 23:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 20:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Thu Nov 23 00:35:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 15:35:13 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 06:57 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 18:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 15:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 14:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 13:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 16:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 13:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Thu Nov 23 00:47:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 15:47:06 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 11:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 23:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 23:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 20:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 20:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 20:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 19:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 18:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 21:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 18:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Thu Nov 23 00:55:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 15:55:43 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 11:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) >Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 23:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 23:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 23:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 20:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 20:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 20:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 19:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 18:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 21:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 18:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Thu Nov 23 01:15:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 16:15:33 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 06:57 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2006-11-22 19:15 Message: Logged In: YES user_id=591932 Originator: NO Thanks to the [ever vigilant] gbrandl I have sf permissions so the patch is now attached below. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 18:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 18:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 18:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 15:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 14:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 13:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 16:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 13:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Thu Nov 23 02:18:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 17:18:41 -0800 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-30 21:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Jiwon Seo (jiwon) Assigned to: Guido van Rossum (gvanrossum) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-11-22 20:18 Message: Logged In: YES user_id=6380 Originator: NO All submitted. (test_keywordonlyarg.py too) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-11-21 23:56 Message: Logged In: YES user_id=6380 Originator: NO Submitted. Jiwon, can you mail me another copy of test_keywordinoyarg.py? I believe I lost it. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-11-21 21:44 Message: Logged In: YES user_id=595483 Originator: YES Now the compiler package works. The patch passes regrtest with "-u all" option and "-u compiler" option (except test_frozen.py). The patch is against latest p3yk branch HEAD. The last patch accidentally included some test code in test_compiler.py (and which is committed to the svn) so this patch includes fix for that. Ah, Guido, when you committed the patch (previous version) last time, you did not add Lib/test/test_keywordonlyarg.py so, this time, don't forget to add it :) Also, last time when we talked, I think you said that the patch makes some test case fail on your laptop machine. You might want to check that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-10-27 19:32 Message: Logged In: YES user_id=6380 Checked in as r52491. I'm keeping this open awaiting a patch for the compiler package. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-10-09 18:22 Message: Logged In: YES user_id=595483 The new patch that I am uploading fixes the Grammar problem - originally I made mistake not allowing *vararg after keyword only argument. The python compiler package doesn't work now, but everything else should work now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-15 13:13 Message: Logged In: YES user_id=6380 I see. The Grammar should simply make the NAME after the '*' optional. Shouldn't be too hard to fix should it? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-14 03:04 Message: Logged In: YES user_id=595483 I made a big mistake with the grammar - currently, the grammar doesn't allow keyword only argument after *vararg. At some point of the development process, I just assumed as such. Underlying logic does not assume anything about that, so I'll try to fix it as soon as possible ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-13 17:16 Message: Logged In: YES user_id=595483 The codeobject has a kwonlyargcount meaning the number of keyword only arguments. Thus, the api for creating new code object is changed: PyCode_New now takes kwonlyargcount. So, the signature changes from this PyCode_New(argcount, nlocals, stacksize, ...) to following. PyCode_New(argcount, kwonlyargcount, nlocals, stacksize, ...) >From python, you can access this with name "co_kwonlyargcount" such as, co.co_kwonlyargcount just like you access argcount with co.co_argcount. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-11 15:51 Message: Logged In: YES user_id=6380 General comment: I think you should update or add a comment explaining the contents of the code object as it has changed (unless that's all described in the PEP). There are a number of places where the code is wider than 79 characters or where the indentatiln style seems to be off. You may have to set your tabstops to 8 spaces to see these. E.g.: ceval.c: - line 2624 should be indented with next line - line 2680 is too long - @@ -2694,13 +2715,35 @@ several lines too long - line 3618 should be indented with the next line ast.c: @@ -591,6 +591,63 @@ please follow the surrounding 4-space indents; don't use tabs here marshal.c: line 871 too long codeobject.c: several lines too long funcobject.c: too long at "non-dict keyword only default args"); Lib/compiler/*.py: several lines too long Lib/test/test_new.py Modules/pyexpat.c: @@ -279,6 +279,7 @@ indentation error Modules/parsermodule.c: several lines too long; the loop at "while (res && i+1 < nch)" is indented one tabstop too many (you seem to have edited this file with ts=4?) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-09-07 13:58 Message: Logged In: YES user_id=595483 The original patch crashes when a function has keyword only arguments but no default values for those arguments, and calls the function without enough arguments. Fixed the bug, and added testcases for that. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:07 Message: Logged In: YES user_id=595483 Maybe I should mention that I've uploaded new patch that fixed what Neal mentioned. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2006-08-31 17:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 01:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Thu Nov 23 12:10:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 03:10:28 -0800 Subject: [Patches] [ python-Patches-1601678 ] sys.id() and sys.intern() Message-ID: Patches item #1601678, was opened at 2006-11-23 11:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1601678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: sys.id() and sys.intern() Initial Comment: This patch moves id() and intern() into the sys module, as listed in PEP 3100. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1601678&group_id=5470 From noreply at sourceforge.net Thu Nov 23 13:11:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 04:11:54 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 21:52 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Neal Norwitz (nnorwitz) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-11-23 12:11 Message: Logged In: YES user_id=4771 Originator: NO Line 20 in demo.py: assert "__getitem__" in dir(x) looks strange to me... Foo doesn't inherit from any sequence or mapping type. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-11 21:31 Message: Logged In: YES user_id=1406776 > PyObject_CallFunctionObjArgs(dirfunc, obj, NULL) done > Couldn't __dir__ also be allowed to return a tuple? no, because tuples are not sortable, and i don't want to over complicate the c-side code of PyObject_Dir. having __dir__ returning only a list is equivalent to __repr__ returning only strings. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 19:58 Message: Logged In: YES user_id=849994 * Instead of doing PyObject_CallFunction(dirfunc, "O", obj) you should do PyObject_CallFunctionObjArgs(dirfunc, obj, NULL). * Couldn't __dir__ also be allowed to return a tuple? ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 11:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 05:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 15:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-06 22:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Thu Nov 23 17:43:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 08:43:26 -0800 Subject: [Patches] [ python-Patches-1601678 ] sys.id() and sys.intern() Message-ID: Patches item #1601678, was opened at 2006-11-23 06:10 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1601678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: sys.id() and sys.intern() Initial Comment: This patch moves id() and intern() into the sys module, as listed in PEP 3100. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-11-23 11:43 Message: Logged In: YES user_id=6380 Originator: NO Aargh. I need to think more about whether I even want this. Doesn't PEP 3100 have a ? near that item? Everything with a ? needs to be reconsidered before implemented. Add a ? if it's not already there for this issue. Sorry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1601678&group_id=5470 From noreply at sourceforge.net Thu Nov 23 21:18:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 12:18:07 -0800 Subject: [Patches] [ python-Patches-1429775 ] Link Python modules to libpython on linux if --enable-shared Message-ID: Patches item #1429775, was opened at 2006-02-11 18:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429775&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Link Python modules to libpython on linux if --enable-shared Initial Comment: The problem description and discussion starts here: http://mail.python.org/pipermail/python-dev/2006-February/060533.html ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-23 21:18 Message: Logged In: YES user_id=21627 Originator: NO It seems that this patch was incorrect, after all, see http://python.org/sf/1600860 gustavo, can you please comment in that bug report? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 14:40 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 45232 ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-02-20 12:28 Message: Logged In: YES user_id=908 Yes; sorry, I didn't notice the other bug. PS: SF bug tracker is horrible ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 11:36 Message: Logged In: YES user_id=1188172 I assume this would resolve bug #832799. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429775&group_id=5470 From noreply at sourceforge.net Fri Nov 24 08:24:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 23:24:12 -0800 Subject: [Patches] [ python-Patches-1602128 ] clarify comparison return values Message-ID: Patches item #1602128, was opened at 2006-11-24 02:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: clarify comparison return values Initial Comment: In the Language Reference section 3.4.1 (http://docs.python.org/ref/customization.html for version 2.5), in the first paragraph where it describes __lt__, __le__, __eq__, __ne__, __gt__, and __ge__, It should mention the special case of NotImplemented, so that people will not be reluctant to return it. (The fourth paragraph suggests returning NotImplemented, but the first suggests that *any* return value will be converted to a boolean, so that NotImplented would mean "True") Please change: """These methods can return any value, but if the comparison operator is used in a Boolean context, the return value should be interpretable as a Boolean value, else a TypeError will be raised. By convention, False is used for false and True for true.""" to: """When an object does not know how to compute a meaningful result, it should return the singleton NotImplemented, in case the other object implements the reflected comparison. By convention, a successful comparison should return either True or False. If any other object is returned in a Boolean context, python will implicitly call bool(result). """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602128&group_id=5470 From noreply at sourceforge.net Fri Nov 24 08:38:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 23:38:32 -0800 Subject: [Patches] [ python-Patches-1602133 ] non-framework built python fails to define environ properly Message-ID: Patches item #1602133, was opened at 2006-11-23 23:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul (ihavetopee) Assigned to: Jack Jansen (jackjansen) Summary: non-framework built python fails to define environ properly Initial Comment: but no one but me seems to build python the unix-y way on darwin/macosx anymore so i guess i'm the only one that cares btw, python without environ defined makes all third party python bindings segfault this has been pissing me off for months only tracked it down yesterday here's my lackluster patch feel free to find something more apropos to conditionalize the diff with and commit it or not i don't care anymore ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602133&group_id=5470 From noreply at sourceforge.net Fri Nov 24 09:57:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 00:57:52 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 13:57 Message generated for change (Comment added) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: ganges master (gangesmaster) Date: 2006-11-24 10:57 Message: Logged In: YES user_id=1406776 Originator: YES well, i liked it better refactored, i.e., each piece of code taking care of one logical part (i.e., one section for __bool__, another for __len__, and another for the default. now it's back to the spaghetti it was. > return PyErr_Occurred() ? -1 : 1; i hate the trinary expression, but that's all about style :) anyway, as long as it works, i don't have any complaints. you just have to make sure it's written as optimized as possible, because it gets invoked many times behind the scenes. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-23 02:15 Message: Logged In: YES user_id=591932 Originator: NO Thanks to the [ever vigilant] gbrandl I have sf permissions so the patch is now attached below. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 01:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 01:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-23 01:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 22:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 22:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 22:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 21:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 20:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 23:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 20:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Fri Nov 24 11:00:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 02:00:41 -0800 Subject: [Patches] [ python-Patches-1602189 ] Suggest a textlist() method for ElementTree Message-ID: Patches item #1602189, was opened at 2006-11-24 05:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602189&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Suggest a textlist() method for ElementTree Initial Comment: This patch has a implementation and example for a method to recursively extract prose from nested XML markup. This improves the utility of ElementTree for documents where otherwise contiguous PCDATA are broken-up by inspersed tags (e.g. xhtml or docbook fragments). See attached file or the ASPN recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498286 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602189&group_id=5470 From noreply at sourceforge.net Sat Nov 25 16:12:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 07:12:42 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 16:57 Message generated for change (Comment added) made by hanwen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- >Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-25 15:12 Message: Logged In: YES user_id=161998 Originator: YES I've sent the agreement by snailmail. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2006-11-17 19:57 Message: Logged In: YES user_id=1368960 Originator: NO I do not mind either. I've just signed and faxed contrib-form.html. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:33 Message: Logged In: YES user_id=161998 Originator: YES note that not all of the patch needs to go in its current form. In particular, setup.py should be much more clever to look into build-root for finding libs and include files. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 00:32 Message: Logged In: YES user_id=161998 Originator: YES I don't mind, and I expect Jan won't have a problem either. What's the procedure: do we send the disclaimer first, or do you do the review, or does everything happen in parallel? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 21:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Sat Nov 25 16:13:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 07:13:50 -0800 Subject: [Patches] [ python-Patches-1366311 ] SRE engine do not release the GIL Message-ID: Patches item #1366311, was opened at 2005-11-25 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1366311&group_id=5470 Please note that this 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: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Eric Noyau (eric_noyau) Assigned to: Fredrik Lundh (effbot) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 16:13 Message: Logged In: YES user_id=21627 Originator: NO I believe the patch is incorrect. While matching, sre may allocate memory through Python API, and it may raise exceptions through Python API. Neither is allowed when the GIL is released Tentatively rejecting the patch. Eric, if you think the patch is correct or can be corrected, please update it to the current subversion trunk. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 00:41 Message: Logged In: YES user_id=1188172 Fredrik, do you have time to review this? ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-28 15:11 Message: Logged In: YES user_id=1388768 Thanks for your comments. I've updated the patch to fix your issues, but without introducing a per-state object lock. What I did instead is to mark a state as not supporting concurrency when a scanner object creates it. So the GIL will not be released for scanners objects at all. For consistency match also release the GIL now, if possible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-11-25 22:38 Message: Logged In: YES user_id=4771 The patch looks good, but I wonder if it is safe. The SRE_STATE structure that SRE_SEARCH_INNER uses is potentially visible to the application-level Python code, via the (undocumented) scanner objects: >>> r = re.compile(r"hello") >>> s = r.scanner("big string in which to search") >>> s.search() <_sre.SRE_Match object at 0x12345678> Each call to s.search() continues the previous search with the same SRE_STATE. The problem with releasing the GIL as you do is that several threads could call s.search() concurrently, which would most probably crash CPython. This probably means that you need to add a lock in SRE_STATE and acquire it while searching, to serialize its usage. Of course, we should then be careful about what overhead this gives to applications that use regexps on a lot of small strings... Another note: for consistency, match() should also release the GIL if search() does. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-25 15:02 Message: Logged In: YES user_id=1388768 I'm attaching a diff to this bug that remove this limitation if it sane to do so. If a search is done on a string or a unicode object (which by definition are immutable) the GIL is released and reacquired everytime a search is done. I've tested this patch in both a simple tests (start a thread with a greedy regex on a monstruous string and verify that the othe python threads are still active) and by running our internal application verifying that nothing is blocking anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1366311&group_id=5470 From noreply at sourceforge.net Sat Nov 25 16:30:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 07:30:11 -0800 Subject: [Patches] [ python-Patches-853963 ] Implement lazy read for sockets Message-ID: Patches item #853963, was opened at 2003-12-04 11:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853963&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Implement lazy read for sockets Initial Comment: When a socket is transformed into a file object using the makefile() method, the resulting object read() behaviour requires that read(N) returns N characters or that the end of stream be reached. This causes problems with XML parsers which call read(BufferSize) to get "something", not necessarily a full buffer. The following patch adds a "lazy" attribute to each socket._fileobject instance, the default being set to False in order to be backward compatible. If this attribute is set to True, read(N) will return at least one character unless the end of stream is reached, and no more than N characters. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 16:30 Message: Logged In: YES user_id=21627 Originator: NO It seems there is very little interest in this patch; it also has a few problems: - it does not include changes to the documentation and the test suite - the feature can be implemented in a fairly easy way by inheriting from _fileobject; you just have to delegate read() nearly directly to recv. - [IMO] "lazy" is a bad name for this feature; it has more to do with whether it is blocking or not. - I don't believe the patch can solve the original problem in all cases: it very much depends on how often the XML parser invokes .read() For these reasons, I'm rejecting the patch. ---------------------------------------------------------------------- Comment By: Samuel Tardieu (samtardieu) Date: 2003-12-04 12:47 Message: Logged In: YES user_id=131394 Note: the original problem description came by Pierre Palatin <pierre.palatin at enst.fr>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853963&group_id=5470 From noreply at sourceforge.net Sat Nov 25 16:40:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 07:40:01 -0800 Subject: [Patches] [ python-Patches-854796 ] Disable POSIX for certain/older NetBSD versions Message-ID: Patches item #854796, was opened at 2003-12-05 16:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Disable POSIX for certain/older NetBSD versions Initial Comment: The attached patch we have in NetBSD's pkgsrc and disables _XOPEN_SOURCE_EXTENDED for NetBSD 1.5*, 1.6, 1.6.* and NetBSD(-current) NetBSD 1.6[A-S]. This are the versions prior _NETBSD_SOURCE. And without this change non-POSIX functions like eg. os.setgroups are unavailable. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 16:40 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r52843 and r52844. ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-12-05 20:18 Message: Logged In: YES user_id=205 Indeed, tt does talk about future versions, but only of the maintenance branch. No interface changes will haben there. (Especially not wrt POSIX). These will happen with NetBSD 2.0 and are in NetBSD-current (1.6[A-Z]*) right now. (So, actually 1.6A is "newer" than 1.6.*) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-05 20:08 Message: Logged In: YES user_id=21627 Doesn't 1.6.* talk about future versions? It should not do that, instead, it should explicitly list all versions to which the patch applies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 From noreply at sourceforge.net Sat Nov 25 16:45:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 07:45:52 -0800 Subject: [Patches] [ python-Patches-858318 ] modsupport does not use va_copy when available Message-ID: Patches item #858318, was opened at 2003-12-11 16:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: modsupport does not use va_copy when available Initial Comment: It appears that the gcc 3.2.2 on SusE linux AMD 64-bit requires the use of va_copy. The attached patch uses va_copy whenever it is #defined. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 16:45 Message: Logged In: YES user_id=21627 Originator: NO Is this patch still needed? Nobody has complained about a problem with va-lists on AMD64 since. Tentatively marking it out-of-date. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-12-11 20:40 Message: Logged In: YES user_id=876734 I've marked this 2.4, but someone (SuSe?) might like it sooner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 From noreply at sourceforge.net Mon Nov 27 14:03:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 05:03:32 -0800 Subject: [Patches] [ python-Patches-1366311 ] SRE engine do not release the GIL Message-ID: Patches item #1366311, was opened at 2005-11-25 13:57 Message generated for change (Comment added) made by eric_noyau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1366311&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Eric Noyau (eric_noyau) Assigned to: Fredrik Lundh (effbot) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- >Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 13:03 Message: Logged In: YES user_id=1388768 Originator: YES Albeit I still think releasing the GIL during regex matching would be beneficial, I agree with Martin that the patch is not good enough for that purpose. I was not aware of the requirement to hold the GIL in order to do memory allocation. Anyway, since implementing this patch, we have reviewed our usage of regex and supressed the really greedy ones. As such this patch is no longer needed by us either. It would probably make our application a tiny fractional bit faster, but not the order of magnitude faster than we experienced before removing the big regexes. In conclusion I thank Martin for the review as I've learned something new, and instead of trying to do a more fine grained fix I'm closing this bug as the current behaviour is good enough if you avoid using stupid regexes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 15:13 Message: Logged In: YES user_id=21627 Originator: NO I believe the patch is incorrect. While matching, sre may allocate memory through Python API, and it may raise exceptions through Python API. Neither is allowed when the GIL is released Tentatively rejecting the patch. Eric, if you think the patch is correct or can be corrected, please update it to the current subversion trunk. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-18 23:41 Message: Logged In: YES user_id=1188172 Fredrik, do you have time to review this? ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-28 14:11 Message: Logged In: YES user_id=1388768 Thanks for your comments. I've updated the patch to fix your issues, but without introducing a per-state object lock. What I did instead is to mark a state as not supporting concurrency when a scanner object creates it. So the GIL will not be released for scanners objects at all. For consistency match also release the GIL now, if possible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-11-25 21:38 Message: Logged In: YES user_id=4771 The patch looks good, but I wonder if it is safe. The SRE_STATE structure that SRE_SEARCH_INNER uses is potentially visible to the application-level Python code, via the (undocumented) scanner objects: >>> r = re.compile(r"hello") >>> s = r.scanner("big string in which to search") >>> s.search() <_sre.SRE_Match object at 0x12345678> Each call to s.search() continues the previous search with the same SRE_STATE. The problem with releasing the GIL as you do is that several threads could call s.search() concurrently, which would most probably crash CPython. This probably means that you need to add a lock in SRE_STATE and acquire it while searching, to serialize its usage. Of course, we should then be careful about what overhead this gives to applications that use regexps on a lot of small strings... Another note: for consistency, match() should also release the GIL if search() does. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-25 14:02 Message: Logged In: YES user_id=1388768 I'm attaching a diff to this bug that remove this limitation if it sane to do so. If a search is done on a string or a unicode object (which by definition are immutable) the GIL is released and reacquired everytime a search is done. I've tested this patch in both a simple tests (start a thread with a greedy regex on a monstruous string and verify that the othe python threads are still active) and by running our internal application verifying that nothing is blocking anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1366311&group_id=5470 From noreply at sourceforge.net Mon Nov 27 18:20:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 09:20:38 -0800 Subject: [Patches] [ python-Patches-1603907 ] subprocess: error redirecting i/o from non-console process Message-ID: Patches item #1603907, was opened at 2006-11-27 17:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1603907&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: error redirecting i/o from non-console process Initial Comment: In IDLE, PythonWin or other non-console interactive Python under Windows: >>> from subprocess import * >>> Popen('cmd', stdout=PIPE) Traceback (most recent call last): File "", line 1, in -toplevel- Popen('', stdout=PIPE) File "C:\python24\lib\subprocess.py", line 533, in __init__ (p2cread, p2cwrite, File "C:\python24\lib\subprocess.py", line 593, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\python24\lib\subprocess.py", line 634, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required The same command in a console windows is successful. Why it happens: subprocess assumes that GetStdHandle always succeeds but when there is no console it returns None. DuplicateHandle then complains about getting a non-integer. This problem does not happen when redirecting all three standard handles. Solution: Replace None with -1 (INVALID_HANDLE_VALUE) in _make_inheritable. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1603907&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:11:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:11:14 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 12:57 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-27 19:11 Message: Logged In: YES user_id=89016 Originator: NO According to http://coverage.livinglogic.de/Objects/typeobject.c.html the code in typeobject.c::slot_nb_nonzero() (for the 2.6 version) gets executed ca. 270000 time during the run of the test suite (compared to e.g. 5700000000 (5.7e9) for the most executed code in ceval.c). So I don't think that performance optimization is *that* critical. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-24 09:57 Message: Logged In: YES user_id=1406776 Originator: YES well, i liked it better refactored, i.e., each piece of code taking care of one logical part (i.e., one section for __bool__, another for __len__, and another for the default. now it's back to the spaghetti it was. > return PyErr_Occurred() ? -1 : 1; i hate the trinary expression, but that's all about style :) anyway, as long as it works, i don't have any complaints. you just have to make sure it's written as optimized as possible, because it gets invoked many times behind the scenes. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-23 01:15 Message: Logged In: YES user_id=591932 Originator: NO Thanks to the [ever vigilant] gbrandl I have sf permissions so the patch is now attached below. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 00:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 00:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-23 00:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 21:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 21:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 21:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 20:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 19:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 22:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 19:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Tue Nov 28 02:30:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 17:30:42 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 06:57 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2006-11-27 20:30 Message: Logged In: YES user_id=591932 Originator: NO intobject.c:int_nonzero() gets called 100 times more than that in the same test run. Actually all builtins go through the fast slots machinery and not slot_nb_nonzero() so I'm not worried about speed (if there is any to be had). I tried adding a nb_bool to listobject.c (currently it falls back on tp_as_mapping->mp_length) and I couldn't tell the difference with ./python Lib/timeit.py "if [] or [] or [] or [] or [] or [] or [] or [] or []: pass" So it looks like the places that matter are already fast. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-27 13:11 Message: Logged In: YES user_id=89016 Originator: NO According to http://coverage.livinglogic.de/Objects/typeobject.c.html the code in typeobject.c::slot_nb_nonzero() (for the 2.6 version) gets executed ca. 270000 time during the run of the test suite (compared to e.g. 5700000000 (5.7e9) for the most executed code in ceval.c). So I don't think that performance optimization is *that* critical. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-24 03:57 Message: Logged In: YES user_id=1406776 Originator: YES well, i liked it better refactored, i.e., each piece of code taking care of one logical part (i.e., one section for __bool__, another for __len__, and another for the default. now it's back to the spaghetti it was. > return PyErr_Occurred() ? -1 : 1; i hate the trinary expression, but that's all about style :) anyway, as long as it works, i don't have any complaints. you just have to make sure it's written as optimized as possible, because it gets invoked many times behind the scenes. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 19:15 Message: Logged In: YES user_id=591932 Originator: NO Thanks to the [ever vigilant] gbrandl I have sf permissions so the patch is now attached below. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 18:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 18:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 18:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 15:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 14:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 13:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 16:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 13:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Tue Nov 28 16:35:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 07:35:57 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 12:57 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-28 16:35 Message: Logged In: YES user_id=89016 Originator: NO OK, so if there are no other objections go ahead and check it in. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-28 02:30 Message: Logged In: YES user_id=591932 Originator: NO intobject.c:int_nonzero() gets called 100 times more than that in the same test run. Actually all builtins go through the fast slots machinery and not slot_nb_nonzero() so I'm not worried about speed (if there is any to be had). I tried adding a nb_bool to listobject.c (currently it falls back on tp_as_mapping->mp_length) and I couldn't tell the difference with ./python Lib/timeit.py "if [] or [] or [] or [] or [] or [] or [] or [] or []: pass" So it looks like the places that matter are already fast. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-27 19:11 Message: Logged In: YES user_id=89016 Originator: NO According to http://coverage.livinglogic.de/Objects/typeobject.c.html the code in typeobject.c::slot_nb_nonzero() (for the 2.6 version) gets executed ca. 270000 time during the run of the test suite (compared to e.g. 5700000000 (5.7e9) for the most executed code in ceval.c). So I don't think that performance optimization is *that* critical. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-24 09:57 Message: Logged In: YES user_id=1406776 Originator: YES well, i liked it better refactored, i.e., each piece of code taking care of one logical part (i.e., one section for __bool__, another for __len__, and another for the default. now it's back to the spaghetti it was. > return PyErr_Occurred() ? -1 : 1; i hate the trinary expression, but that's all about style :) anyway, as long as it works, i don't have any complaints. you just have to make sure it's written as optimized as possible, because it gets invoked many times behind the scenes. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-23 01:15 Message: Logged In: YES user_id=591932 Originator: NO Thanks to the [ever vigilant] gbrandl I have sf permissions so the patch is now attached below. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 00:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 00:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-23 00:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 21:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 21:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 21:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 20:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 19:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 22:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 19:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Tue Nov 28 20:20:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 11:20:23 -0800 Subject: [Patches] [ python-Patches-1600346 ] __bool__ instead of __nonzero__ Message-ID: Patches item #1600346, was opened at 2006-11-21 06:57 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Jack Diederich (jackdied) Summary: __bool__ instead of __nonzero__ Initial Comment: this patch replaces __nonzero__ with __bool__, to make bool type symmetrical to all other types (__int__, __float__, etc.) some notes: * the latex docs have been updated * the slot name was changed from nb_nonzero to nb_bool * all XXX_nonzero methods where changed to XXX_bool * all the comments relating to nb_nonzero have been updated * stdlib was updated * all the test suites were updated otoh, i couldn't get it to compile (MSVC++2003), because of a strange bug in ceval.c (none of my code). seems the GETLOCAL macro causes syntactic problems, but i didn't have time to check it thoroughly. ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2006-11-28 14:20 Message: Logged In: YES user_id=591932 Originator: NO Committed revision 52853 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-28 10:35 Message: Logged In: YES user_id=89016 Originator: NO OK, so if there are no other objections go ahead and check it in. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-27 20:30 Message: Logged In: YES user_id=591932 Originator: NO intobject.c:int_nonzero() gets called 100 times more than that in the same test run. Actually all builtins go through the fast slots machinery and not slot_nb_nonzero() so I'm not worried about speed (if there is any to be had). I tried adding a nb_bool to listobject.c (currently it falls back on tp_as_mapping->mp_length) and I couldn't tell the difference with ./python Lib/timeit.py "if [] or [] or [] or [] or [] or [] or [] or [] or []: pass" So it looks like the places that matter are already fast. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-27 13:11 Message: Logged In: YES user_id=89016 Originator: NO According to http://coverage.livinglogic.de/Objects/typeobject.c.html the code in typeobject.c::slot_nb_nonzero() (for the 2.6 version) gets executed ca. 270000 time during the run of the test suite (compared to e.g. 5700000000 (5.7e9) for the most executed code in ceval.c). So I don't think that performance optimization is *that* critical. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-24 03:57 Message: Logged In: YES user_id=1406776 Originator: YES well, i liked it better refactored, i.e., each piece of code taking care of one logical part (i.e., one section for __bool__, another for __len__, and another for the default. now it's back to the spaghetti it was. > return PyErr_Occurred() ? -1 : 1; i hate the trinary expression, but that's all about style :) anyway, as long as it works, i don't have any complaints. you just have to make sure it's written as optimized as possible, because it gets invoked many times behind the scenes. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 19:15 Message: Logged In: YES user_id=591932 Originator: NO Thanks to the [ever vigilant] gbrandl I have sf permissions so the patch is now attached below. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 18:55 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-22 18:47 Message: Logged In: YES user_id=849994 Originator: NO Applies and compiles fine here. I was about to comment about a refleak somewhere (I ran test_iter with -R and it showed 222 leaked refs), but it shows up without the patch too. I'll update PEP 3100 after you checked it in, so that people writing the conversion tool/advisor will remember to include this one. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 18:35 Message: Logged In: YES user_id=591932 Originator: NO I don't have sf permissions so I put a tweaked version of the patch at http://jackdied.com/static/bool6.patch * keeps slots_nb_bool closer to the original * extra test in test_bool to exercise __len__ fallbacks * test_iter and test_decimal pass * reverted longobject.c indentation The regular __len__ machinery does get called but the 2.5 code does the bool/int check either way because it made the code shorter (both __len__ and __nonzero__ could return an int so doing the same check for both didn't hurt anything). The new patch treats the result of __len__ and __bool__ slightly differently because __bool__ must return __bool__. I added a couple lines but otherwise left the function as it was (so the lookup_maybe()s should be fine) If there are no objections I'll check it in. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:43 Message: Logged In: YES user_id=1406776 Originator: YES > In the > new code it looks like func will get decrefed if it is NULL > but PyErr_Occurred is not set. true. i neglected that :) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 15:30 Message: Logged In: YES user_id=591932 Originator: NO Ah, I missed the default of -1 The refactoring changed how the results of lookup_maybe()s are used. From the note at the top of lookup_maybe() it might return NULL and _not_ set an exception. In the old code it checked for NULL versus PyErr_Occcurred. In the new code it looks like func will get decrefed if it is NULL but PyErr_Occurred is not set. I would revert the refactoring and change only the bits you have to. [I'll pass on the __len__ thing until I have a chance to look at it more] ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-22 15:07 Message: Logged In: YES user_id=1406776 Originator: YES > There used to be a "result = -1;" result is initialized to -1 at the beginning of the function > did you mean to reindent the long_as_number struct in longobject.c? i realigned the struct with tab of 4, where it used to be tabs of 8, so things got messed up a little. i tried my best to fix it, but i can't fix what i can't see :) > bool5.patch removes the check for int for the __len__() result as this is > already done in the __len__() call itself no it's not! we are not using PyObject_Len, we directly invoke __len__, which may return anything it wishes. you can't skip that check. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-22 14:58 Message: Logged In: YES user_id=591932 Originator: NO I'm not convinced slot_nb_bool is doing the right thing in the PyBool_Check(tmp) line. There used to be a "result = -1;" right after the PyErr_Format and there isn't anymore (maybe result gets set to -1 somewhere else but I can't tell where). Can you undo the refactoring of that function in general? Some of the decrefs moved around too and they look correct but it would be easier to tell if they just stayed the same. Also, did you mean to reindent the long_as_number struct in longobject.c? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-22 13:55 Message: Logged In: YES user_id=89016 Originator: NO bool5.patch removes the check for int for the __len__() result as this is already done in the __len__() call itself. It adds a few tests to test_bool.py::BoolTest.test_convert_to_bool() and fixes the description of __bool__ in Doc/ref/ref3.tex. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 16:33 Message: Logged In: YES user_id=1406776 Originator: YES fixed a bug with type checking when using __len__ ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-21 13:28 Message: Logged In: YES user_id=1406776 Originator: YES * slot_nb_bool now requires __bool__ to return only a boolean * tab-width issues (hopefully) fixed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1600346&group_id=5470 From noreply at sourceforge.net Wed Nov 29 06:49:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 21:49:19 -0800 Subject: [Patches] [ python-Patches-1605020 ] Performance boost for array repeat Message-ID: Patches item #1605020, was opened at 2006-11-28 21:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Performance boost for array repeat Initial Comment: Copy in exponentially-increasing sized chunks when performing array repeat. This enables fast initialization of large arrays. Performance is about an order of magnitude increase for single-element arrays, and about two orders of magnitude faster for single-element character arrays (see comments) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 From noreply at sourceforge.net Wed Nov 29 06:54:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 21:54:53 -0800 Subject: [Patches] [ python-Patches-1605020 ] Performance boost for array repeat Message-ID: Patches item #1605020, was opened at 2006-11-28 21:49 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Performance boost for array repeat Initial Comment: Copy in exponentially-increasing sized chunks when performing array repeat. This enables fast initialization of large arrays. Performance is about an order of magnitude increase for single-element arrays, and about two orders of magnitude faster for single-element character arrays (see comments) ---------------------------------------------------------------------- >Comment By: Mike Klaas (mklaas) Date: 2006-11-28 21:54 Message: Logged In: YES user_id=1611720 Originator: YES Benchmarks on slightly-contended machine; before & after [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0')*100000" 100 loops, best of 3: 4 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0')*100000" 100000 loops, best of 3: 14.5 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('i', [0])*100000" 100 loops, best of 3: 3.42 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('i', [0])*100000" 1000 loops, best of 3: 517 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('i', [0,1,2,3])*100000" 100 loops, best of 3: 4.95 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('i', [0,1,2,3])*100000" 100 loops, best of 3: 2.55 msec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0'*100)*1000" 10000 loops, best of 3: 46.6 usec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0'*100)*1000" 100000 loops, best of 3: 19.6 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0'*1000)*100" 10000 loops, best of 3: 22.8 usec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0'*1000)*100" 10000 loops, best of 3: 20.7 usec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 From noreply at sourceforge.net Wed Nov 29 10:31:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 01:31:01 -0800 Subject: [Patches] [ python-Patches-1605020 ] Performance boost for array repeat Message-ID: Patches item #1605020, was opened at 2006-11-29 05:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Performance boost for array repeat Initial Comment: Copy in exponentially-increasing sized chunks when performing array repeat. This enables fast initialization of large arrays. Performance is about an order of magnitude increase for single-element arrays, and about two orders of magnitude faster for single-element character arrays (see comments) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-29 09:31 Message: Logged In: YES user_id=849994 Originator: NO How does this patch relate to patch #1569291? ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-11-29 05:54 Message: Logged In: YES user_id=1611720 Originator: YES Benchmarks on slightly-contended machine; before & after [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0')*100000" 100 loops, best of 3: 4 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0')*100000" 100000 loops, best of 3: 14.5 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('i', [0])*100000" 100 loops, best of 3: 3.42 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('i', [0])*100000" 1000 loops, best of 3: 517 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('i', [0,1,2,3])*100000" 100 loops, best of 3: 4.95 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('i', [0,1,2,3])*100000" 100 loops, best of 3: 2.55 msec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0'*100)*1000" 10000 loops, best of 3: 46.6 usec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0'*100)*1000" 100000 loops, best of 3: 19.6 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0'*1000)*100" 10000 loops, best of 3: 22.8 usec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0'*1000)*100" 10000 loops, best of 3: 20.7 usec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 From noreply at sourceforge.net Wed Nov 29 12:52:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 03:52:04 -0800 Subject: [Patches] [ python-Patches-1605192 ] Make Imap Error more helpful Message-ID: Patches item #1605192, was opened at 2006-11-29 11:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Make Imap Error more helpful Initial Comment: Hi, In my app I got this error: imaplib.error: command SEARCH illegal in state AUTH. but I did successfully login. After reading the source of imaplib.py I realized that this was meant: imaplib.error: command SEARCH illegal in state AUTH. Allowed after: SELECTED Attached is a small patch to make the error message more helpful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605192&group_id=5470 From noreply at sourceforge.net Wed Nov 29 19:25:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 10:25:43 -0800 Subject: [Patches] [ python-Patches-1605020 ] Performance boost for array repeat Message-ID: Patches item #1605020, was opened at 2006-11-28 21:49 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Performance boost for array repeat Initial Comment: Copy in exponentially-increasing sized chunks when performing array repeat. This enables fast initialization of large arrays. Performance is about an order of magnitude increase for single-element arrays, and about two orders of magnitude faster for single-element character arrays (see comments) ---------------------------------------------------------------------- >Comment By: Mike Klaas (mklaas) Date: 2006-11-29 10:25 Message: Logged In: YES user_id=1611720 Originator: YES The patches have virtually identical functionality and performance characteristics. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-29 01:31 Message: Logged In: YES user_id=849994 Originator: NO How does this patch relate to patch #1569291? ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-11-28 21:54 Message: Logged In: YES user_id=1611720 Originator: YES Benchmarks on slightly-contended machine; before & after [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0')*100000" 100 loops, best of 3: 4 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0')*100000" 100000 loops, best of 3: 14.5 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('i', [0])*100000" 100 loops, best of 3: 3.42 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('i', [0])*100000" 1000 loops, best of 3: 517 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('i', [0,1,2,3])*100000" 100 loops, best of 3: 4.95 msec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('i', [0,1,2,3])*100000" 100 loops, best of 3: 2.55 msec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0'*100)*1000" 10000 loops, best of 3: 46.6 usec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0'*100)*1000" 100000 loops, best of 3: 19.6 usec per loop [ python-trunk]$ python -m timeit -s "from array import array" "array('c', '\0'*1000)*100" 10000 loops, best of 3: 22.8 usec per loop [ python-trunk]$ ./python -m timeit -s "from array import array" "array('c', '\0'*1000)*100" 10000 loops, best of 3: 20.7 usec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605020&group_id=5470 From noreply at sourceforge.net Wed Nov 29 22:05:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 13:05:20 -0800 Subject: [Patches] [ python-Patches-1298835 ] vendor-packages directory. Message-ID: Patches item #1298835, was opened at 2005-09-22 17:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Rich Burridge (richburridge) Assigned to: Nobody/Anonymous (nobody) Summary: vendor-packages directory. Initial Comment: Python needs a .../python2.x.y/vendor-packages directory for vendor supplied Python files. See: http://mail.python.org/pipermail/python-list/2005-September/300029.html for the full reasoning behind this request. I also approached Guido w.r.t. this. Here's his reply. Subject: Re: Python vendor-packages directory in a future Python release? Date: Tue, 20 Sep 2005 19:48:40 -0700 From: Guido van Rossum Reply-To: Guido van Rossum To: Rich Burridge References: <4330C108.4030100 at sun.com> I think that's a reasonable request. (In the mean time, I think that using site-packages is fine as an interim solution.) I suggest that you use the SourceForge patch manager for the Python project to upload your patch, and then post to python-dev. You may be asked to review 5 other patches in order to have someone look at your favorite patch. --Guido ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 22:05 Message: Logged In: YES user_id=21627 Originator: NO Guido van Rossum suggests a vendor-packages directory in http://mail.python.org/pipermail/python-dev/2006-November/070063.html I'm reopening the patch to encourage further review. ---------------------------------------------------------------------- Comment By: Rich Burridge (richburridge) Date: 2005-09-29 16:47 Message: Logged In: YES user_id=511506 A good alternative solution to this problem was given on the python-devel mailing list. See: http://mail.python.org/pipermail/python-dev/2005-September/056697.html http://mail.python.org/pipermail/python-dev/2005-September/056699.html The architectural commitee have approved this solution, so I'm closing this bug as "Invalid". If there'd been a "Withdrawn" resolution, I'd have closed it that way instead. Perhaps that's what Deleted is supposed to do. Feel free to tweak if I've selected the wrong closure. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-24 01:49 Message: Logged In: YES user_id=593130 The reason for this patch given in the referred-to post is: "We have been told that this directory is inappropriate for vendor supplied packages, just as "site_perl" is inappropriate for Perl. With Perl, vendor supplied packages go under "vendor_perl". " where 'this directory' is site-packages, which works fine. The python-dev thread subequent to this posting starts with http://mail.python.org/pipermail/python-dev/2005- September/056682.html A subsequent post http://mail.python.org/pipermail/python-dev/2005- September/056696.html clarifies that 'vendor supplied packages' here means packages installed by the system/OS vendor. Disconnected (in the pipermail archives) pieces of the thread start here http://mail.python.org/pipermail/python-dev/2005- September/056697.html and here http://mail.python.org/pipermail/python-dev/2005- September/056702.html This last suggests that this proposal is on hold while a .pth solution is explored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298835&group_id=5470 From noreply at sourceforge.net Thu Nov 30 02:18:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 17:18:10 -0800 Subject: [Patches] [ python-Patches-1599845 ] TCPServer option to bind and activate Message-ID: Patches item #1599845, was opened at 2006-11-20 12:15 Message generated for change (Comment added) made by parente You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: TCPServer option to bind and activate Initial Comment: Adds a flag to the TCPServer constructor to automatically call server_bind and server_activate or not. Setting this flag to False gives the programmer the chance to manipulate allow_reuse_address on the instance without having to subclass TCPServer or its derivatives just to change the flag. Adds this flag to SimpleXMLRPCServer.__init__ also. See bug #1595742. ---------------------------------------------------------------------- >Comment By: Peter Parente (parente) Date: 2006-11-29 20:18 Message: Logged In: YES user_id=624776 Originator: YES I marked the parameter as new to Python 2.6 in the documentation. Is this correct? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 01:50 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide documentation patches as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:10:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:10:28 -0800 Subject: [Patches] [ python-Patches-810754 ] socket.ssl should check certificates Message-ID: Patches item #810754, was opened at 2003-09-22 18:30 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 Please note that this 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.2.x Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Damjan Georgievski (gdamjan) Assigned to: Martin v. L?wis (loewis) Summary: socket.ssl should check certificates Initial Comment: I've decided to post here the patch proposed by Ed Phillips, since I think it's simple addition to the socket.ssl that will drastically increase its usefullness... The point of the patch is for a socket.ssl object to check the certificate received by the peer. http://mail.python.org/pipermail/python-list/2003-July/174933.html ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 20:10 Message: Logged In: YES user_id=5571 Originator: NO This should be reopened. Just because the proposed fix didn't work is no reason to close the defect report. Currently, Python will accept the following totally bogus certificate (from www.amaison.co.uk) as valid: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Issuer identity: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-26 16:47 Message: Logged In: YES user_id=21627 I think you are mis-interpreting the purpose of the key_file and cert_file arguments. They do *not* indicate the certificate of the trusted CAs, but provide the key and certificate of the *client*. By re-interpreting the cert_file as the file of the trusted CAs, you break client-side authentication. Therefore, i reject this patch. That said, I do agree that checking server-side certificates is a useful think, so I encourage you to provide a new patch which does that, e.g. by adding a certificate_chain_file argument (or some such). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:13:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:13:37 -0800 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 23:04 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 20:13 Message: Logged In: YES user_id=5571 Originator: NO This has been pending for a few months, and there's a fix, but it's not in yet. What's going on? I just had Python accept a totally bogus certificate from "www.amaison.co.uk". The certificate contents are C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Issuer identity: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Python is perfectly happy with that. Which is embarassing. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-09 15:20 Message: Logged In: YES user_id=908 > This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). Are you sure it's a good idea to have this kind of 'global' control over certification authorities? Global configurations are handy at first, but they come back and bite us when we least expect it... ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2006-11-09 14:43 Message: Logged In: YES user_id=31389 Nagle: I haven't heard anything from anyone besides you and jbowes abou this patch here or on the python-dev list, and I haven't had time to follow up. You might have more success via the email list. (Or, if any of the python maintainers is reading this, do you have any suggestions to make this patch more attractive?) ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-09 04:14 Message: Logged In: YES user_id=5571 What's the status of this? Is it going in? I have a need for it. Thanks. ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 19:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:18:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:18:16 -0800 Subject: [Patches] [ python-Patches-810754 ] socket.ssl should check certificates Message-ID: Patches item #810754, was opened at 2003-09-22 18:30 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 Please note that this 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.2.x Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Damjan Georgievski (gdamjan) Assigned to: Martin v. L?wis (loewis) Summary: socket.ssl should check certificates Initial Comment: I've decided to post here the patch proposed by Ed Phillips, since I think it's simple addition to the socket.ssl that will drastically increase its usefullness... The point of the patch is for a socket.ssl object to check the certificate received by the peer. http://mail.python.org/pipermail/python-list/2003-July/174933.html ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 20:18 Message: Logged In: YES user_id=5571 Originator: NO Same bug, with different patch, is at: [ 1114345 ] Add SSL certificate validation ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 20:10 Message: Logged In: YES user_id=5571 Originator: NO This should be reopened. Just because the proposed fix didn't work is no reason to close the defect report. Currently, Python will accept the following totally bogus certificate (from www.amaison.co.uk) as valid: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Issuer identity: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-26 16:47 Message: Logged In: YES user_id=21627 I think you are mis-interpreting the purpose of the key_file and cert_file arguments. They do *not* indicate the certificate of the trusted CAs, but provide the key and certificate of the *client*. By re-interpreting the cert_file as the file of the trusted CAs, you break client-side authentication. Therefore, i reject this patch. That said, I do agree that checking server-side certificates is a useful think, so I encourage you to provide a new patch which does that, e.g. by adding a certificate_chain_file argument (or some such). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:43:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:43:40 -0800 Subject: [Patches] [ python-Patches-810754 ] socket.ssl should check certificates Message-ID: Patches item #810754, was opened at 2003-09-22 20:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 Please note that this 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.2.x Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Damjan Georgievski (gdamjan) Assigned to: Martin v. L?wis (loewis) Summary: socket.ssl should check certificates Initial Comment: I've decided to post here the patch proposed by Ed Phillips, since I think it's simple addition to the socket.ssl that will drastically increase its usefullness... The point of the patch is for a socket.ssl object to check the certificate received by the peer. http://mail.python.org/pipermail/python-list/2003-July/174933.html ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-30 21:43 Message: Logged In: YES user_id=21627 Originator: NO This was a patch submission, asking that the proposed patch is integrated. I rejected the patch, and the issue is done. If you want to report a bug, please do so as a separate issue (you may include a patch also, but then the description should clearly state what the bug is - this issue doesn't). Of course, as a bug report, it may stay open unreviewed for several years if no patch is contributed that fixes it. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 21:18 Message: Logged In: YES user_id=5571 Originator: NO Same bug, with different patch, is at: [ 1114345 ] Add SSL certificate validation ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 21:10 Message: Logged In: YES user_id=5571 Originator: NO This should be reopened. Just because the proposed fix didn't work is no reason to close the defect report. Currently, Python will accept the following totally bogus certificate (from www.amaison.co.uk) as valid: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Issuer identity: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-26 17:47 Message: Logged In: YES user_id=21627 I think you are mis-interpreting the purpose of the key_file and cert_file arguments. They do *not* indicate the certificate of the trusted CAs, but provide the key and certificate of the *client*. By re-interpreting the cert_file as the file of the trusted CAs, you break client-side authentication. Therefore, i reject this patch. That said, I do agree that checking server-side certificates is a useful think, so I encourage you to provide a new patch which does that, e.g. by adding a certificate_chain_file argument (or some such). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=810754&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:50:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:50:01 -0800 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-02 00:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-30 21:50 Message: Logged In: YES user_id=21627 Originator: NO The patch is not integrated because nobody had the time to review it; this, in turn, did not happen because we lack reviewers. A quick review reveals that the patch is incomplete: it does not provide changes to the documentation (which it needs to, because it introduces a new feature). The patch also includes no changes to the test suite. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 21:13 Message: Logged In: YES user_id=5571 Originator: NO This has been pending for a few months, and there's a fix, but it's not in yet. What's going on? I just had Python accept a totally bogus certificate from "www.amaison.co.uk". The certificate contents are C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Issuer identity: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Python is perfectly happy with that. Which is embarassing. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-09 16:20 Message: Logged In: YES user_id=908 > This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). Are you sure it's a good idea to have this kind of 'global' control over certification authorities? Global configurations are handy at first, but they come back and bite us when we least expect it... ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2006-11-09 15:43 Message: Logged In: YES user_id=31389 Nagle: I haven't heard anything from anyone besides you and jbowes abou this patch here or on the python-dev list, and I haven't had time to follow up. You might have more success via the email list. (Or, if any of the python maintainers is reading this, do you have any suggestions to make this patch more attractive?) ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-09 05:14 Message: Logged In: YES user_id=5571 What's the status of this? Is it going in? I have a need for it. Thanks. ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 21:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 From noreply at sourceforge.net Thu Nov 30 22:09:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 13:09:51 -0800 Subject: [Patches] [ python-Patches-1114345 ] Add SSL certificate validation Message-ID: Patches item #1114345, was opened at 2005-02-01 15:04 Message generated for change (Comment added) made by noonian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Eagan (noonian) Assigned to: Nobody/Anonymous (nobody) Summary: Add SSL certificate validation Initial Comment: One line summary: adds certificate validation to the SSL module and programmer-level hooks to control how and whether certificate validation is performed. Details: The current SSL implementation in python goes through the motions of negotiating an SSL connection, but never validates the certificates exchanged. This is like going through the motions of checking someone's photo id, but never making sure the picture matches the person you're talking to. This patch fixes that. This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). If certificate verification is enabled, then one of the two certificate authority parameters must be set to a valid certificate authority database or all certificate verification operations will fail. I have an example certificate authority database (extracted from the Java keystore) that I can provide, but I'm not sure how to contribute that through the patch mechanism. Cheers! James Eagan ---------------------------------------------------------------------- >Comment By: James Eagan (noonian) Date: 2006-11-30 13:09 Message: Logged In: YES user_id=31389 Originator: YES I'd be happy to make the changes l?wis suggested, but it will be quite a while before I can find the necessary time. If anyone else can update the docs and tests, please let me know! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-30 12:50 Message: Logged In: YES user_id=21627 Originator: NO The patch is not integrated because nobody had the time to review it; this, in turn, did not happen because we lack reviewers. A quick review reveals that the patch is incomplete: it does not provide changes to the documentation (which it needs to, because it introduces a new feature). The patch also includes no changes to the test suite. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-30 12:13 Message: Logged In: YES user_id=5571 Originator: NO This has been pending for a few months, and there's a fix, but it's not in yet. What's going on? I just had Python accept a totally bogus certificate from "www.amaison.co.uk". The certificate contents are C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Issuer identity: C = -- ST = SomeState L = SomeCity O = SomeOrganization OU = SomeOrganizationalUnit CN = localhost.localdomain emailAddress = root at localhost.localdomain Python is perfectly happy with that. Which is embarassing. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-09 07:20 Message: Logged In: YES user_id=908 > This patch adds 3 module-level variables to the socket module, which get exposed iff ssl is built in. These variables (ssl_ca_file, ssl_ca_path, and ssl_verify_level) provide programmer-level access to the certificate authorities database and to control what level of certificate verification is performed (by default, none, as is the current behavior). Are you sure it's a good idea to have this kind of 'global' control over certification authorities? Global configurations are handy at first, but they come back and bite us when we least expect it... ---------------------------------------------------------------------- Comment By: James Eagan (noonian) Date: 2006-11-09 06:43 Message: Logged In: YES user_id=31389 Nagle: I haven't heard anything from anyone besides you and jbowes abou this patch here or on the python-dev list, and I haven't had time to follow up. You might have more success via the email list. (Or, if any of the python maintainers is reading this, do you have any suggestions to make this patch more attractive?) ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-08 20:14 Message: Logged In: YES user_id=5571 What's the status of this? Is it going in? I have a need for it. Thanks. ---------------------------------------------------------------------- Comment By: James Bowes (jbowes) Date: 2006-06-21 12:43 Message: Logged In: YES user_id=1543815 I put together an updated version of this patch against svn trunk as of June 21, 2006. I also added some additional documentation to the .tex file. Maybe someone with sufficient privilidges (or James, if you're still out there) could attach the updated patch here? the updated patch is at: http://www.dangerouslyinc.com/~bowes/ssl_ca.diff Regards, James Bowes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1114345&group_id=5470