From noreply at sourceforge.net Tue Aug 1 00:32:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 15:32:39 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 05:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) >Assigned to: Georg Brandl (gbrandl) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 22:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 18:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 18:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 19:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Aug 1 01:03:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 16:03:15 -0700 Subject: [Patches] [ python-Patches-1520879 ] make install change: Allow $DESTDIR to be relative Message-ID: Patches item #1520879, was opened at 2006-07-11 23:56 Message generated for change (Comment added) made by dgreiman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520879&group_id=5470 Please note that this 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 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: make install change: Allow $DESTDIR to be relative Initial Comment: This patch allows the $DESTDIR variable used in 'make install' to be a relative path. It also avoids constructing filenames starting with double slashes ('//') when DESTDIR is an absolute path. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- >Comment By: Douglas Greiman (dgreiman) Date: 2006-07-31 23:03 Message: Logged In: YES user_id=1553997 That seems reasonable, however I believe it should be a separate change since codewise the two changes are unrelated. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 21:13 Message: Logged In: YES user_id=340931 I'd also like to see the argument to 'configure --prefix=' also be relative. Could this patch be expanded in that direction? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520879&group_id=5470 From noreply at sourceforge.net Tue Aug 1 01:12:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 16:12:10 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 00:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 18:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 17:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 13:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 13:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 14:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Aug 1 02:30:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 17:30:03 -0700 Subject: [Patches] [ python-Patches-1531859 ] Tracing and profiling functions can cause hangs in threads Message-ID: Patches item #1531859, was opened at 2006-07-31 16:48 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Tracing and profiling functions can cause hangs in threads Initial Comment: Attached is a patch (with test case) that fixes a problem when a tracing function or a profiling function for a thread references a thread ID, causing it to hang. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-01 00:30 Message: Logged In: YES user_id=1126061 Actually the problem is a little different than I first reliased. I've updated the comment block above the code in threading.py's __delete method to more clearly explain the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 From noreply at sourceforge.net Tue Aug 1 05:56:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 20:56:09 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this 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: Closed >Resolution: Rejected Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From postmaster at rgu.ac.uk Tue Aug 1 11:09:47 2006 From: postmaster at rgu.ac.uk (postmaster at rgu.ac.uk) Date: Tue, 1 Aug 2006 10:09:47 +0100 Subject: [Patches] McAfee GroupShield Alert Message-ID: <000601c6b54a$3c568bb0$475442c2@rgu.ac.uk> McAfee GroupShield? Alert McAfee GroupShield discovered a problem with the following email. See your system administrator for further information. Date/Time sent: 01 Aug 2006 10:09:47 Subject line: impressao!! From: patches at python.org To: Robert Halsall (absrwh) Action taken: Deleted Message Reason: File Filter Rule Group: Forbidden Attachment Copyright ? 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeesecurity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20060801/7610b545/attachment.html From noreply at sourceforge.net Tue Aug 1 15:21:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 06:21:50 -0700 Subject: [Patches] [ python-Patches-1528167 ] Support for case-insensitivity in string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Settings changed) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Open >Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) >Summary: Support for case-insensitivity in string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Aug 1 15:24:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 06:24:42 -0700 Subject: [Patches] [ python-Patches-1528167 ] Support for case-insensitivity in string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for case-insensitivity in string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 09:24 Message: Logged In: YES user_id=12800 Yes, that would be much more acceptable! ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Aug 1 15:28:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 06:28:05 -0700 Subject: [Patches] [ python-Patches-1531859 ] Tracing and profiling functions can cause hangs in threads Message-ID: Patches item #1531859, was opened at 2006-07-31 12:48 Message generated for change (Comment added) made by rockyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Tracing and profiling functions can cause hangs in threads Initial Comment: Attached is a patch (with test case) that fixes a problem when a tracing function or a profiling function for a thread references a thread ID, causing it to hang. Matt ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 09:28 Message: Logged In: YES user_id=158581 I would like to try to clarify the problem a little and suggest some possible solution approaches. While this patch solves a particular threading.settrace() problem (and possibly a potential threading.setprofile problem), the more I think about this, I'm not sure it will solve all of them or is necessary in all cases. To reiterate the problem: It was noticed that having tracing (Threading.settrace) or profiling turned on while inside threading.py can cause a thread hang when _active_limbo_lock.aquire() is called recursively: once while code uses a method in threading.py like _delete(), and another time when tracing or profiling routine is called by settrace from within a Threading method and the tracing/profiling code calls one of the Threading methods like enumerate() to get information for its own purposes. (The patch addresses this for _delete but I'm not sure it would address it if the first call were say enumerate). One possibility and clearly the most reliable one because it relies least on code using Threading, would be for threading.py to check for this kind of recursive invocation (at the module level, not the method level) which might be done by scanning a call stack. More later. Another possibility might be to document this behavior and put the burden on the profiler/debugger/tracer or anything that might cause some set of threading routines to be called recursively. To address the problem outside of Threading code, what might be done is call _active_limbo_lock.aquire(blocking=0) before calling a Threading routine like enumerate(), and use the Threading routine only only if the lock is acquired. This will work, but it may get the "cannot acquire lock" status too often, namely in situations where there isn't a recursive call. Better than this would again be to somehow indicate that "a call to a Threading routine which does locking" is in progress. A simple and reliable way to do this would be to share the responsibility: the Threading methods would set a boolean variable set to indicate this condition. Code using Threading could test this before making calls which would cause recursive invocation. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-31 20:30 Message: Logged In: YES user_id=1126061 Actually the problem is a little different than I first reliased. I've updated the comment block above the code in threading.py's __delete method to more clearly explain the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 From noreply at sourceforge.net Tue Aug 1 16:07:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 07:07:25 -0700 Subject: [Patches] [ python-Patches-1528167 ] Support for case-insensitivity in string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for case-insensitivity in string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-08-01 10:07 Message: Logged In: YES user_id=340931 Ok, here it is! I added a test but wasn't sure this warranted a doc change. Cf.: http://docs.python.org/dev/lib/node40.html ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 09:24 Message: Logged In: YES user_id=12800 Yes, that would be much more acceptable! ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Aug 1 16:26:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 07:26:11 -0700 Subject: [Patches] [ python-Patches-1531859 ] Tracing and profiling functions can cause hangs in threads Message-ID: Patches item #1531859, was opened at 2006-07-31 12:48 Message generated for change (Comment added) made by rockyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Tracing and profiling functions can cause hangs in threads Initial Comment: Attached is a patch (with test case) that fixes a problem when a tracing function or a profiling function for a thread references a thread ID, causing it to hang. Matt ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 10:26 Message: Logged In: YES user_id=158581 One change to my comment below. I now don't think the "share the responsibility" approach mentioned will work any differently than the approach where the user of Threading adds active_limbo_lock.aquire(blocking=0) calls. The most reliable then is scanning the call stack, but this requires knowledge of the internals of Threading.py. This knowledge could be eliminated thouhg. On entry to a locking routine, a local variable could be set and instead of scanning the call stack for method names and file names (threading.py) a scan could be done for that local variable. Going further Threading could provide a routine to do the stack scan. ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 09:28 Message: Logged In: YES user_id=158581 I would like to try to clarify the problem a little and suggest some possible solution approaches. While this patch solves a particular threading.settrace() problem (and possibly a potential threading.setprofile problem), the more I think about this, I'm not sure it will solve all of them or is necessary in all cases. To reiterate the problem: It was noticed that having tracing (Threading.settrace) or profiling turned on while inside threading.py can cause a thread hang when _active_limbo_lock.aquire() is called recursively: once while code uses a method in threading.py like _delete(), and another time when tracing or profiling routine is called by settrace from within a Threading method and the tracing/profiling code calls one of the Threading methods like enumerate() to get information for its own purposes. (The patch addresses this for _delete but I'm not sure it would address it if the first call were say enumerate). One possibility and clearly the most reliable one because it relies least on code using Threading, would be for threading.py to check for this kind of recursive invocation (at the module level, not the method level) which might be done by scanning a call stack. More later. Another possibility might be to document this behavior and put the burden on the profiler/debugger/tracer or anything that might cause some set of threading routines to be called recursively. To address the problem outside of Threading code, what might be done is call _active_limbo_lock.aquire(blocking=0) before calling a Threading routine like enumerate(), and use the Threading routine only only if the lock is acquired. This will work, but it may get the "cannot acquire lock" status too often, namely in situations where there isn't a recursive call. Better than this would again be to somehow indicate that "a call to a Threading routine which does locking" is in progress. A simple and reliable way to do this would be to share the responsibility: the Threading methods would set a boolean variable set to indicate this condition. Code using Threading could test this before making calls which would cause recursive invocation. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-31 20:30 Message: Logged In: YES user_id=1126061 Actually the problem is a little different than I first reliased. I've updated the comment block above the code in threading.py's __delete method to more clearly explain the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 From noreply at sourceforge.net Tue Aug 1 16:29:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 07:29:50 -0700 Subject: [Patches] [ python-Patches-1528167 ] Tweak to make string.Templates more customizable Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Settings changed) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) >Summary: Tweak to make string.Templates more customizable Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 10:07 Message: Logged In: YES user_id=340931 Ok, here it is! I added a test but wasn't sure this warranted a doc change. Cf.: http://docs.python.org/dev/lib/node40.html ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 09:24 Message: Logged In: YES user_id=12800 Yes, that would be much more acceptable! ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Aug 1 17:28:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 08:28:47 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-02 01:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 04:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-30 02:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Tue Aug 1 17:53:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 08:53:04 -0700 Subject: [Patches] [ python-Patches-1531859 ] Tracing and profiling functions can cause hangs in threads Message-ID: Patches item #1531859, was opened at 2006-07-31 16:48 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Tracing and profiling functions can cause hangs in threads Initial Comment: Attached is a patch (with test case) that fixes a problem when a tracing function or a profiling function for a thread references a thread ID, causing it to hang. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-01 15:53 Message: Logged In: YES user_id=1126061 Your first solution, where the threading module in the standard library would check for any sort of recursion problem before trying to acquire the _active_limbo_lock, if say, it _does_ try to acquire _active_limbo_lock is it's already locked, what is the solution? It's probably not a good idea for threading.enumerate() to not return anything. How about unsetting/resetting the _trace_hook/_profile_hook around locked sections of code? This is pretty much the same as the developer of a tracing function using your idea of asking for _active_limbo_lock in their func except that it'd be transparent to them. This might be a vialbe solution, as long as it's clearly documented somewhere that this is what happens. It might just be a better solution to paste something in the threading docs such as "Don't call these functions from within tracing functions in threaded code" and a list of functions that are problematic, leaving the responsibility of this solely on the developer. I have no idea. But yes, thanks for pulling me up on the fact taht this patch is incomplete and doesn't fix all cases. Matt ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 14:26 Message: Logged In: YES user_id=158581 One change to my comment below. I now don't think the "share the responsibility" approach mentioned will work any differently than the approach where the user of Threading adds active_limbo_lock.aquire(blocking=0) calls. The most reliable then is scanning the call stack, but this requires knowledge of the internals of Threading.py. This knowledge could be eliminated thouhg. On entry to a locking routine, a local variable could be set and instead of scanning the call stack for method names and file names (threading.py) a scan could be done for that local variable. Going further Threading could provide a routine to do the stack scan. ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 13:28 Message: Logged In: YES user_id=158581 I would like to try to clarify the problem a little and suggest some possible solution approaches. While this patch solves a particular threading.settrace() problem (and possibly a potential threading.setprofile problem), the more I think about this, I'm not sure it will solve all of them or is necessary in all cases. To reiterate the problem: It was noticed that having tracing (Threading.settrace) or profiling turned on while inside threading.py can cause a thread hang when _active_limbo_lock.aquire() is called recursively: once while code uses a method in threading.py like _delete(), and another time when tracing or profiling routine is called by settrace from within a Threading method and the tracing/profiling code calls one of the Threading methods like enumerate() to get information for its own purposes. (The patch addresses this for _delete but I'm not sure it would address it if the first call were say enumerate). One possibility and clearly the most reliable one because it relies least on code using Threading, would be for threading.py to check for this kind of recursive invocation (at the module level, not the method level) which might be done by scanning a call stack. More later. Another possibility might be to document this behavior and put the burden on the profiler/debugger/tracer or anything that might cause some set of threading routines to be called recursively. To address the problem outside of Threading code, what might be done is call _active_limbo_lock.aquire(blocking=0) before calling a Threading routine like enumerate(), and use the Threading routine only only if the lock is acquired. This will work, but it may get the "cannot acquire lock" status too often, namely in situations where there isn't a recursive call. Better than this would again be to somehow indicate that "a call to a Threading routine which does locking" is in progress. A simple and reliable way to do this would be to share the responsibility: the Threading methods would set a boolean variable set to indicate this condition. Code using Threading could test this before making calls which would cause recursive invocation. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-01 00:30 Message: Logged In: YES user_id=1126061 Actually the problem is a little different than I first reliased. I've updated the comment block above the code in threading.py's __delete method to more clearly explain the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 From noreply at sourceforge.net Tue Aug 1 18:01:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 09:01:11 -0700 Subject: [Patches] [ python-Patches-1531859 ] Tracing and profiling functions can cause hangs in threads Message-ID: Patches item #1531859, was opened at 2006-07-31 12:48 Message generated for change (Comment added) made by rockyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Tracing and profiling functions can cause hangs in threads Initial Comment: Attached is a patch (with test case) that fixes a problem when a tracing function or a profiling function for a thread references a thread ID, causing it to hang. Matt ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 12:01 Message: Logged In: YES user_id=158581 threading.enumerate() could raise an error. I'm curious though to learn what others think of various aspects of the problem. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-01 11:53 Message: Logged In: YES user_id=1126061 Your first solution, where the threading module in the standard library would check for any sort of recursion problem before trying to acquire the _active_limbo_lock, if say, it _does_ try to acquire _active_limbo_lock is it's already locked, what is the solution? It's probably not a good idea for threading.enumerate() to not return anything. How about unsetting/resetting the _trace_hook/_profile_hook around locked sections of code? This is pretty much the same as the developer of a tracing function using your idea of asking for _active_limbo_lock in their func except that it'd be transparent to them. This might be a vialbe solution, as long as it's clearly documented somewhere that this is what happens. It might just be a better solution to paste something in the threading docs such as "Don't call these functions from within tracing functions in threaded code" and a list of functions that are problematic, leaving the responsibility of this solely on the developer. I have no idea. But yes, thanks for pulling me up on the fact taht this patch is incomplete and doesn't fix all cases. Matt ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 10:26 Message: Logged In: YES user_id=158581 One change to my comment below. I now don't think the "share the responsibility" approach mentioned will work any differently than the approach where the user of Threading adds active_limbo_lock.aquire(blocking=0) calls. The most reliable then is scanning the call stack, but this requires knowledge of the internals of Threading.py. This knowledge could be eliminated thouhg. On entry to a locking routine, a local variable could be set and instead of scanning the call stack for method names and file names (threading.py) a scan could be done for that local variable. Going further Threading could provide a routine to do the stack scan. ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-08-01 09:28 Message: Logged In: YES user_id=158581 I would like to try to clarify the problem a little and suggest some possible solution approaches. While this patch solves a particular threading.settrace() problem (and possibly a potential threading.setprofile problem), the more I think about this, I'm not sure it will solve all of them or is necessary in all cases. To reiterate the problem: It was noticed that having tracing (Threading.settrace) or profiling turned on while inside threading.py can cause a thread hang when _active_limbo_lock.aquire() is called recursively: once while code uses a method in threading.py like _delete(), and another time when tracing or profiling routine is called by settrace from within a Threading method and the tracing/profiling code calls one of the Threading methods like enumerate() to get information for its own purposes. (The patch addresses this for _delete but I'm not sure it would address it if the first call were say enumerate). One possibility and clearly the most reliable one because it relies least on code using Threading, would be for threading.py to check for this kind of recursive invocation (at the module level, not the method level) which might be done by scanning a call stack. More later. Another possibility might be to document this behavior and put the burden on the profiler/debugger/tracer or anything that might cause some set of threading routines to be called recursively. To address the problem outside of Threading code, what might be done is call _active_limbo_lock.aquire(blocking=0) before calling a Threading routine like enumerate(), and use the Threading routine only only if the lock is acquired. This will work, but it may get the "cannot acquire lock" status too often, namely in situations where there isn't a recursive call. Better than this would again be to somehow indicate that "a call to a Threading routine which does locking" is in progress. A simple and reliable way to do this would be to share the responsibility: the Threading methods would set a boolean variable set to indicate this condition. Code using Threading could test this before making calls which would cause recursive invocation. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-31 20:30 Message: Logged In: YES user_id=1126061 Actually the problem is a little different than I first reliased. I've updated the comment block above the code in threading.py's __delete method to more clearly explain the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 From noreply at sourceforge.net Tue Aug 1 20:17:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 11:17:09 -0700 Subject: [Patches] [ python-Patches-1520905 ] Don't produce core file in test_subprocess.py Message-ID: Patches item #1520905, was opened at 2006-07-11 21:18 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: A.M. Kuchling (akuchling) Summary: Don't produce core file in test_subprocess.py Initial Comment: The test_run_abort() testcase in test_subprocess.py produces a core file on Unix systems, even though the test is successful. This can be confusing or alarming to someone who runs 'make test' and then finds that the Python interpreter apparently crashed. Tested on Red Hat Linux 9 on x86. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-01 14:17 Message: Logged In: YES user_id=11375 Committed to trunk in rev.51021. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Douglas Greiman (dgreiman) Date: 2006-07-31 16:35 Message: Logged In: YES user_id=1553997 No, I don't have commit privileges. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-31 16:23 Message: Logged In: YES user_id=11375 >From reading the patch, the fix looks good. Do you have commit privileges, or do I need to check in the change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:30:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:30:03 -0700 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 08:31 Message generated for change (Comment added) made by jwnmulder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: Accepted Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for mbcs codecs Initial Comment: Hello. I have noticed mbcs codecs sometimes generates broken string. I'm using Windows(Japanese) so mbcs is mapped to cp932 (close to shift_jis) When I run the attached script "a.zip", the entry "Error 00007"'s message becomes broken like attached file "b.txt". I think this happens because the string passed to PyUnicode_DecodeMBCS() sometimes terminates with leading byte, and MultiByteToWideChar() counts it for size of result string.buffer size. I hope attached patch "mbcs.patch" may fix the problem. It would be nice if this bug will be fixed in 2.4.3... Thank you. ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 23:30 Message: Logged In: YES user_id=770969 could be related to bug report 1532726 ? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-25 20:46 Message: Logged In: YES user_id=1200846 >>I think the default value for final in mbcs_decode() should >>be true, so that the stateless decoder detects incomplete >>byte sequences too. > >Probably this is not true. Sorry, I lied. Stateless decoder was exactly the thing you said. >>> import codecs >>> d = codecs.getdecoder("cp932") >>> d('\x82') Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'cp932' codec can't decode byte 0x82 in position 0: incomplete multibyte sequence Problem was on StreamReader. StreamReader should treat "final" as false, but I didn't change this code, class StreamReader(Codec,codecs.StreamReader): pass so StreamReader wrongly treated "final" as True. I cloned routine from Lib/encoding/utf-8.py. I hope finally this meets requirement of codec system... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-25 18:17 Message: Logged In: YES user_id=1200846 Sorry, I reopened this issue because I found problem. With attached "mbcs.py" and "mbcs.txt", result file "hoge.txt" gets corrupted. This happens because Codec.decode is called incrementally, while default value for final in mbcs_decode() is True. >I think the default value for final in mbcs_decode() should >be true, so that the stateless decoder detects incomplete >byte sequences too. Probably this is not true. I think "stateless" means codec doesn't have internal state for incremental usage, doesn't mean it is not called incrementally. # I hope attached "fix.patch" fixes the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-14 07:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46945. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:40 Message: Logged In: YES user_id=1200846 I reverted PyUnicode_Resize() patch for now, and recreated the patch as "mbcs.patch". >You should probably find someone on python-dev with a >multibyte version of Windows to look at the patch. OK, I will. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:18 Message: Logged In: YES user_id=1200846 >The change to PyUnicode_Resize() should be reverted (or done >in a way that doesn't lead to bugs). Sorry, how about this? Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 46417) +++ Objects/unicodeobject.c (working copy) @@ -326,7 +326,7 @@ return -1; } v = (PyUnicodeObject *)*unicode; - if (v == NULL || !PyUnicode_Check(v) || v->ob_refcnt != 1 || length < 0) { + if (v == NULL || !PyUnicode_Check(v) || length < 0) { PyErr_BadInternalCall(); return -1; } @@ -335,7 +335,7 @@ possible since these are being shared. We simply return a fresh copy with the same Unicode content. */ if (v->length != length && - (v == unicode_empty || v->length == 1)) { + (v == unicode_empty || v->length == 1 || v->ob_refcnt != 1)) { PyUnicodeObject *w = _PyUnicode_New(length); if (w == NULL) return -1; ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-05-26 17:43 Message: Logged In: YES user_id=89016 The change to PyUnicode_Resize() should be reverted (or done in a way that doesn't lead to bugs). Unfortunately I don't have a Windows where I can test the patch, so I'm unassigning the bug. You should probably find someone on python-dev with a multibyte version of Windows to look at the patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:06 Message: Logged In: YES user_id=1200846 >PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, >but probably I'll fix it too. Done. Attached as "mbcs_win64_support.patch". Now, total summary... - MBCS decoder and encoder now supports 64bit Py_ssize_t environment. (I don't have such machine, but I checked routine by defining NEED_RETRY and redefining INT_MAX as 2, 3, 4) - Fixed a bug of MBCS incremental decoder which was originaly reported by me. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-24 22:18 Message: Logged In: YES user_id=1200846 I updated the patch. - PyUnicode_DecodeMBCS now supports size >= INT_MAX. (I don't have machine to test such big string, but I have tested this routine replaced INT_MAX with 2 and 3) PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, but probably I'll fix it too. This patch includes Patch#1494487. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-02 13:40 Message: Logged In: YES user_id=1200846 I updated the patch. (I copy and pasted "int final = 0" from above code (ex: utf_16_ex_decode), maybe they also should be changed for consistency?) And one more thing, I noticed "errors" is ignored now. We can detect invalid character if we set MB_ERR_INVALID_CHARS flag when calling MultiByteToWideChar, but we cannot tell where is the position of invalid character, and MSDN saids this flag is available Win2000SP4 or later (I don't know why) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp So I didn't make the patch for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-25 19:22 Message: Logged In: YES user_id=89016 I think the default value for final in mbcs_decode() should be true, so that the stateless decoder detects incomplete byte sequences too. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-04-07 11:10 Message: Logged In: YES user_id=1200846 I have sent contributor form via postal mail. Probably you can get it after 10 days. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 10:16 Message: Logged In: YES user_id=1200846 You are right. I've updated the patch. (mbcs5.patch) >>> import codecs [20198 refs] >>> d = codecs.getincrementaldecoder("mbcs")() [20198 refs] >>> d.decode('\x82\xa0\x82') u'\u3042' [20198 refs] >>> d.decode('') u'' [20198 refs] >>> d.decode('', final=True) u'\x00' [20198 refs] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-27 18:06 Message: Logged In: YES user_id=89016 _buffer_decode() in the IncrementalDecoder ignores the final argument. IncrementalDecoder._buffer_decode() should pass on its final argument to _codecsmodules.c::mbcs_decode(), which should be extended to accept the final argument. Also PyUnicode_DecodeMBCSStateful() must handle consumed == NULL correctly (with your patch it drops trailing lead bytes even if consumed == NULL) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 09:41 Message: Logged In: YES user_id=1200846 I replaced tests. Probably this is better instead of comparing the two string generated by same decoder. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 07:44 Message: Logged In: YES user_id=1200846 My real name is Hirokazu Yamamoto. But sorry, I don't have FAX. (It's needed to send contributor form, isn't it?) I'll attach the patch updated for trunk. And I'll attach the tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-26 23:05 Message: Logged In: YES user_id=21627 I have reservations against this patch because of the quasi-anonymous nature of the submission. ocean-city, can you please state your real name? Would you also be willing to fill out a contributor form, as shown on http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-24 15:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-23 22:44 Message: Logged In: YES user_id=89016 This isn't a bugfix in the strictest sense, so IMHO this patch shouldn't go into 2.4. If the patch goes into 2.5, it would need the appropriate changes to encodings/mbcs.py (i.e. the IncrementalDecoder would have to be changed (inheriting from BufferedIncrementalDecoder). I realize that this patch might be hard to test, as results are dependent on locale. Nevertheless at least some tests would be good (even if they are only run or do something useful on a certain locale and are skipped otherwise). ocean-city, can you update the patch for the trunk and add tests? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-23 03:51 Message: Logged In: YES user_id=1200846 Hello. This is my final patch. (mbcs4.patch) - mbcs3a.patch: _mbsbtype depends on locale not system ANSI code page. so probably it's not good to use it with MultiByteToWideChar. - mbcs3b.patch: CharNext may cause buffer overflow. and this patch always calls CharPrev but it's not needed if string is not terminated with "potensial" lead byte. I hope this is stable enough to commit on repositry. Thank you. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 15:36 Message: Logged In: YES user_id=1200846 Sorry, I was stupid. MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp) saids, > IsDBCSLeadByte can only indicate a potential lead byte value. IsDBCSLeadByte was returning 1 for some trail byte (ex: "?"[1]) The patch "mbcs3a.patch" worked for me, but _mbsbtype is probably compiler specific. Is that OK? The patch "mbcs3b.patch" also worked for me and it only uses Win32API, but I don't have enough faith on this implementation... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:31 Message: Logged In: YES user_id=1200846 Sorry, I found problem when tried more long text file... Please wait. I'll investigate more intensibly. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:13 Message: Logged In: YES user_id=1200846 Thank you for reply. How about this? (I'm a newbie, I hope this is right tex format but... can you confirm this? I created this patch by copy & paste from PyUnicode_DecodeUTF16Stateful and some modification) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:12 Message: Logged In: YES user_id=38388 One more nit: the doc patch is missing. Please add a patch for the API docs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:11 Message: Logged In: YES user_id=38388 As I understand your comment, the mbcs codec will have a problem if the input string terminates with a lead byte. Could you add a comment regarding this to the patch ?! I can't test the patch, since I don't have a Japanese Windows to check on, but from looking at the patch, it seems OK. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 08:42 Message: Logged In: YES user_id=1200846 I forgot to mention this. "mbcs.patch" is for release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Aug 2 04:12:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 19:12:22 -0700 Subject: [Patches] [ python-Patches-1528167 ] Tweak to make string.Templates more customizable Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Tweak to make string.Templates more customizable Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 22:12 Message: Logged In: YES user_id=12800 Looks good to me. Remind us when we fork the trunk. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 10:07 Message: Logged In: YES user_id=340931 Ok, here it is! I added a test but wasn't sure this warranted a doc change. Cf.: http://docs.python.org/dev/lib/node40.html ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 09:24 Message: Logged In: YES user_id=12800 Yes, that would be much more acceptable! ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Wed Aug 2 08:48:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 23:48:18 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 16:02 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 8 Submitted By: Tony Nelson (tony_nelson) >Assigned to: Neal Norwitz (nnorwitz) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-01 23:48 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51039. (2.5) ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 14:56 Message: Logged In: YES user_id=1356214 I'm pretty sure that the bug would affect MSWindows. I don't know how to make the test work without sending a signal, such as signal.alarm() or os.kill(), which don't seem to be available on other platforms. I've marked the test with XXX and a comment as requested. I've posed the question on python-dev. Should I ask there for specific help writing the test? The test in this version of the patch has fewer race conditions (and reports the bug differently) than the previous test. The functional part of the patch is unchanged. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 11:23 Message: Logged In: YES user_id=33168 Does the bug affect Windows? A test that only runs on Unix is better than nothing. If the test can't be fixed to run on Windows, please add a comment with an XXX to discuss this and try to get someone to impl a Windows version. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 07:36 Message: Logged In: YES user_id=1356214 Darn. My test will only work on *nix, and not on other platforms such as MSWindows. I don't see a way to send a signal that would work on all platforms, so I don't know a way to test the patch. I'll have to ask for help. The test may need to be changed to only test on *nix. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 20:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 18:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Wed Aug 2 09:38:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 00:38:03 -0700 Subject: [Patches] [ python-Patches-1494140 ] Documentation for new Struct object Message-ID: Patches item #1494140, was opened at 2006-05-24 09:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for new Struct object Initial Comment: The performance enhancements to the struct module (patch #1493701) are implemented by having a Struct object, which is a compiled structure. This text file documents these new struct objects. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-02 07:38 Message: Logged In: YES user_id=849994 New/renamed functions need a \versionadded/changed. For StructObjects, I'd suggest a sentence like "Struct objects are new in version 2.5" at the top of the section. There's no explanation how to create a Struct object. The constructor must be explained, preferably on the module overview page. Isn't the type name "Struct"? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-07-30 17:33 Message: Logged In: YES user_id=671362 > Does this patch still need to be updated for pack_to() I suppose so and hence updated my patch. (1) document pack_into(pack_to is renamed to pack_into). (2) document pack_into/pack_from as module functions too(just like re module) As for the function name change, I've already updated "what's new in 2.5" in r50985. I guess the patch is ready to be applied. Reviews are appreciated. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 19:28 Message: Logged In: YES user_id=11375 Does this patch still need to be updated for pack_to(), or can it just be applied? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-07-10 17:26 Message: Logged In: YES user_id=671362 Patch for the TeX style doc. Bob, can you work on updating the main section right after 2.5 b2? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-26 13:05 Message: Logged In: YES user_id=139309 We're going to need to revise this patch some more to document the new pack_to function (for Martin Blais' hotbuf work) Additionally we'll probably also want to revise the main struct documentation to talk about bounds checking and avoiding the creation of long objects. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 14:32 Message: Logged In: YES user_id=139309 That's clearly a typo. I've attached a new version of the patch that removes those two letters. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-24 21:03 Message: Logged In: YES user_id=764593 Shouldn't self.size be the number of bytes required to *pack * the structure? The number required to *unpack* seems like it ought to include tuple overhead and such... ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 15:35 Message: Logged In: YES user_id=139309 New patch attached, fixed unpack documentation, added unpack_from method. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 14:54 Message: Logged In: YES user_id=139309 Hold up on this patch, I need to revise it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 From noreply at sourceforge.net Wed Aug 2 09:57:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 00:57:05 -0700 Subject: [Patches] [ python-Patches-1532975 ] Replace the ctypes internal '_as_parameter_' mechanism Message-ID: Patches item #1532975, was opened at 2006-08-02 09: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=1532975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Replace the ctypes internal '_as_parameter_' mechanism Initial Comment: This patch removes the '_as_parameter_' public attribute of ctypes instances, and replaces the mechanism by an internal one. This mechanism is used to convert a ctypes instance to an (internal) PyCArgObject instance which can directly by used as an argument in a C function call. With this patch, a C function pointer which does create the PyCArgObject instance is stored in the type dictionary (an StgDict instance). This does speed up foreign function calls with one ctypes argument by about 20%, but more important, it will allow to fix the '_as_parameter_' mechanism, which is documented in [1], so that it actually will work as describes, even for functions that have 'argtypes' set. [1] http://docs.python.org/dev/lib/ctypes-calling-functions-with-own-custom-data-types.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 From noreply at sourceforge.net Wed Aug 2 09:59:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 00:59:57 -0700 Subject: [Patches] [ python-Patches-1532975 ] Replace the ctypes internal '_as_parameter_' mechanism Message-ID: Patches item #1532975, was opened at 2006-08-02 09:57 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Replace the ctypes internal '_as_parameter_' mechanism Initial Comment: This patch removes the '_as_parameter_' public attribute of ctypes instances, and replaces the mechanism by an internal one. This mechanism is used to convert a ctypes instance to an (internal) PyCArgObject instance which can directly by used as an argument in a C function call. With this patch, a C function pointer which does create the PyCArgObject instance is stored in the type dictionary (an StgDict instance). This does speed up foreign function calls with one ctypes argument by about 20%, but more important, it will allow to fix the '_as_parameter_' mechanism, which is documented in [1], so that it actually will work as describes, even for functions that have 'argtypes' set. [1] http://docs.python.org/dev/lib/ctypes-calling-functions-with-own-custom-data-types.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 From noreply at sourceforge.net Wed Aug 2 15:01:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 06:01:09 -0700 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 08:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: Accepted Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for mbcs codecs Initial Comment: Hello. I have noticed mbcs codecs sometimes generates broken string. I'm using Windows(Japanese) so mbcs is mapped to cp932 (close to shift_jis) When I run the attached script "a.zip", the entry "Error 00007"'s message becomes broken like attached file "b.txt". I think this happens because the string passed to PyUnicode_DecodeMBCS() sometimes terminates with leading byte, and MultiByteToWideChar() counts it for size of result string.buffer size. I hope attached patch "mbcs.patch" may fix the problem. It would be nice if this bug will be fixed in 2.4.3... Thank you. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-02 15:01 Message: Logged In: YES user_id=21627 jwnmulder: there is definitely no relationship. ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 23:30 Message: Logged In: YES user_id=770969 could be related to bug report 1532726 ? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-25 20:46 Message: Logged In: YES user_id=1200846 >>I think the default value for final in mbcs_decode() should >>be true, so that the stateless decoder detects incomplete >>byte sequences too. > >Probably this is not true. Sorry, I lied. Stateless decoder was exactly the thing you said. >>> import codecs >>> d = codecs.getdecoder("cp932") >>> d('\x82') Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'cp932' codec can't decode byte 0x82 in position 0: incomplete multibyte sequence Problem was on StreamReader. StreamReader should treat "final" as false, but I didn't change this code, class StreamReader(Codec,codecs.StreamReader): pass so StreamReader wrongly treated "final" as True. I cloned routine from Lib/encoding/utf-8.py. I hope finally this meets requirement of codec system... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-25 18:17 Message: Logged In: YES user_id=1200846 Sorry, I reopened this issue because I found problem. With attached "mbcs.py" and "mbcs.txt", result file "hoge.txt" gets corrupted. This happens because Codec.decode is called incrementally, while default value for final in mbcs_decode() is True. >I think the default value for final in mbcs_decode() should >be true, so that the stateless decoder detects incomplete >byte sequences too. Probably this is not true. I think "stateless" means codec doesn't have internal state for incremental usage, doesn't mean it is not called incrementally. # I hope attached "fix.patch" fixes the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-14 07:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46945. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:40 Message: Logged In: YES user_id=1200846 I reverted PyUnicode_Resize() patch for now, and recreated the patch as "mbcs.patch". >You should probably find someone on python-dev with a >multibyte version of Windows to look at the patch. OK, I will. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:18 Message: Logged In: YES user_id=1200846 >The change to PyUnicode_Resize() should be reverted (or done >in a way that doesn't lead to bugs). Sorry, how about this? Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 46417) +++ Objects/unicodeobject.c (working copy) @@ -326,7 +326,7 @@ return -1; } v = (PyUnicodeObject *)*unicode; - if (v == NULL || !PyUnicode_Check(v) || v->ob_refcnt != 1 || length < 0) { + if (v == NULL || !PyUnicode_Check(v) || length < 0) { PyErr_BadInternalCall(); return -1; } @@ -335,7 +335,7 @@ possible since these are being shared. We simply return a fresh copy with the same Unicode content. */ if (v->length != length && - (v == unicode_empty || v->length == 1)) { + (v == unicode_empty || v->length == 1 || v->ob_refcnt != 1)) { PyUnicodeObject *w = _PyUnicode_New(length); if (w == NULL) return -1; ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-05-26 17:43 Message: Logged In: YES user_id=89016 The change to PyUnicode_Resize() should be reverted (or done in a way that doesn't lead to bugs). Unfortunately I don't have a Windows where I can test the patch, so I'm unassigning the bug. You should probably find someone on python-dev with a multibyte version of Windows to look at the patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:06 Message: Logged In: YES user_id=1200846 >PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, >but probably I'll fix it too. Done. Attached as "mbcs_win64_support.patch". Now, total summary... - MBCS decoder and encoder now supports 64bit Py_ssize_t environment. (I don't have such machine, but I checked routine by defining NEED_RETRY and redefining INT_MAX as 2, 3, 4) - Fixed a bug of MBCS incremental decoder which was originaly reported by me. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-24 22:18 Message: Logged In: YES user_id=1200846 I updated the patch. - PyUnicode_DecodeMBCS now supports size >= INT_MAX. (I don't have machine to test such big string, but I have tested this routine replaced INT_MAX with 2 and 3) PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, but probably I'll fix it too. This patch includes Patch#1494487. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-02 13:40 Message: Logged In: YES user_id=1200846 I updated the patch. (I copy and pasted "int final = 0" from above code (ex: utf_16_ex_decode), maybe they also should be changed for consistency?) And one more thing, I noticed "errors" is ignored now. We can detect invalid character if we set MB_ERR_INVALID_CHARS flag when calling MultiByteToWideChar, but we cannot tell where is the position of invalid character, and MSDN saids this flag is available Win2000SP4 or later (I don't know why) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp So I didn't make the patch for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-25 19:22 Message: Logged In: YES user_id=89016 I think the default value for final in mbcs_decode() should be true, so that the stateless decoder detects incomplete byte sequences too. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-04-07 11:10 Message: Logged In: YES user_id=1200846 I have sent contributor form via postal mail. Probably you can get it after 10 days. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 10:16 Message: Logged In: YES user_id=1200846 You are right. I've updated the patch. (mbcs5.patch) >>> import codecs [20198 refs] >>> d = codecs.getincrementaldecoder("mbcs")() [20198 refs] >>> d.decode('\x82\xa0\x82') u'\u3042' [20198 refs] >>> d.decode('') u'' [20198 refs] >>> d.decode('', final=True) u'\x00' [20198 refs] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-27 18:06 Message: Logged In: YES user_id=89016 _buffer_decode() in the IncrementalDecoder ignores the final argument. IncrementalDecoder._buffer_decode() should pass on its final argument to _codecsmodules.c::mbcs_decode(), which should be extended to accept the final argument. Also PyUnicode_DecodeMBCSStateful() must handle consumed == NULL correctly (with your patch it drops trailing lead bytes even if consumed == NULL) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 09:41 Message: Logged In: YES user_id=1200846 I replaced tests. Probably this is better instead of comparing the two string generated by same decoder. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 07:44 Message: Logged In: YES user_id=1200846 My real name is Hirokazu Yamamoto. But sorry, I don't have FAX. (It's needed to send contributor form, isn't it?) I'll attach the patch updated for trunk. And I'll attach the tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-26 23:05 Message: Logged In: YES user_id=21627 I have reservations against this patch because of the quasi-anonymous nature of the submission. ocean-city, can you please state your real name? Would you also be willing to fill out a contributor form, as shown on http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-24 15:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-23 22:44 Message: Logged In: YES user_id=89016 This isn't a bugfix in the strictest sense, so IMHO this patch shouldn't go into 2.4. If the patch goes into 2.5, it would need the appropriate changes to encodings/mbcs.py (i.e. the IncrementalDecoder would have to be changed (inheriting from BufferedIncrementalDecoder). I realize that this patch might be hard to test, as results are dependent on locale. Nevertheless at least some tests would be good (even if they are only run or do something useful on a certain locale and are skipped otherwise). ocean-city, can you update the patch for the trunk and add tests? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-23 03:51 Message: Logged In: YES user_id=1200846 Hello. This is my final patch. (mbcs4.patch) - mbcs3a.patch: _mbsbtype depends on locale not system ANSI code page. so probably it's not good to use it with MultiByteToWideChar. - mbcs3b.patch: CharNext may cause buffer overflow. and this patch always calls CharPrev but it's not needed if string is not terminated with "potensial" lead byte. I hope this is stable enough to commit on repositry. Thank you. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 15:36 Message: Logged In: YES user_id=1200846 Sorry, I was stupid. MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp) saids, > IsDBCSLeadByte can only indicate a potential lead byte value. IsDBCSLeadByte was returning 1 for some trail byte (ex: "?"[1]) The patch "mbcs3a.patch" worked for me, but _mbsbtype is probably compiler specific. Is that OK? The patch "mbcs3b.patch" also worked for me and it only uses Win32API, but I don't have enough faith on this implementation... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:31 Message: Logged In: YES user_id=1200846 Sorry, I found problem when tried more long text file... Please wait. I'll investigate more intensibly. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:13 Message: Logged In: YES user_id=1200846 Thank you for reply. How about this? (I'm a newbie, I hope this is right tex format but... can you confirm this? I created this patch by copy & paste from PyUnicode_DecodeUTF16Stateful and some modification) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:12 Message: Logged In: YES user_id=38388 One more nit: the doc patch is missing. Please add a patch for the API docs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:11 Message: Logged In: YES user_id=38388 As I understand your comment, the mbcs codec will have a problem if the input string terminates with a lead byte. Could you add a comment regarding this to the patch ?! I can't test the patch, since I don't have a Japanese Windows to check on, but from looking at the patch, it seems OK. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 08:42 Message: Logged In: YES user_id=1200846 I forgot to mention this. "mbcs.patch" is for release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Aug 2 15:54:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 06:54:46 -0700 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 08:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for mbcs codecs Initial Comment: Hello. I have noticed mbcs codecs sometimes generates broken string. I'm using Windows(Japanese) so mbcs is mapped to cp932 (close to shift_jis) When I run the attached script "a.zip", the entry "Error 00007"'s message becomes broken like attached file "b.txt". I think this happens because the string passed to PyUnicode_DecodeMBCS() sometimes terminates with leading byte, and MultiByteToWideChar() counts it for size of result string.buffer size. I hope attached patch "mbcs.patch" may fix the problem. It would be nice if this bug will be fixed in 2.4.3... Thank you. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-02 15:54 Message: Logged In: YES user_id=21627 Thanks for the update. Committed as r51046. Please create new a new patch the next time you need to further changes. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-02 15:01 Message: Logged In: YES user_id=21627 jwnmulder: there is definitely no relationship. ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 23:30 Message: Logged In: YES user_id=770969 could be related to bug report 1532726 ? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-25 20:46 Message: Logged In: YES user_id=1200846 >>I think the default value for final in mbcs_decode() should >>be true, so that the stateless decoder detects incomplete >>byte sequences too. > >Probably this is not true. Sorry, I lied. Stateless decoder was exactly the thing you said. >>> import codecs >>> d = codecs.getdecoder("cp932") >>> d('\x82') Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'cp932' codec can't decode byte 0x82 in position 0: incomplete multibyte sequence Problem was on StreamReader. StreamReader should treat "final" as false, but I didn't change this code, class StreamReader(Codec,codecs.StreamReader): pass so StreamReader wrongly treated "final" as True. I cloned routine from Lib/encoding/utf-8.py. I hope finally this meets requirement of codec system... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-25 18:17 Message: Logged In: YES user_id=1200846 Sorry, I reopened this issue because I found problem. With attached "mbcs.py" and "mbcs.txt", result file "hoge.txt" gets corrupted. This happens because Codec.decode is called incrementally, while default value for final in mbcs_decode() is True. >I think the default value for final in mbcs_decode() should >be true, so that the stateless decoder detects incomplete >byte sequences too. Probably this is not true. I think "stateless" means codec doesn't have internal state for incremental usage, doesn't mean it is not called incrementally. # I hope attached "fix.patch" fixes the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-14 07:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46945. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:40 Message: Logged In: YES user_id=1200846 I reverted PyUnicode_Resize() patch for now, and recreated the patch as "mbcs.patch". >You should probably find someone on python-dev with a >multibyte version of Windows to look at the patch. OK, I will. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-26 23:18 Message: Logged In: YES user_id=1200846 >The change to PyUnicode_Resize() should be reverted (or done >in a way that doesn't lead to bugs). Sorry, how about this? Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 46417) +++ Objects/unicodeobject.c (working copy) @@ -326,7 +326,7 @@ return -1; } v = (PyUnicodeObject *)*unicode; - if (v == NULL || !PyUnicode_Check(v) || v->ob_refcnt != 1 || length < 0) { + if (v == NULL || !PyUnicode_Check(v) || length < 0) { PyErr_BadInternalCall(); return -1; } @@ -335,7 +335,7 @@ possible since these are being shared. We simply return a fresh copy with the same Unicode content. */ if (v->length != length && - (v == unicode_empty || v->length == 1)) { + (v == unicode_empty || v->length == 1 || v->ob_refcnt != 1)) { PyUnicodeObject *w = _PyUnicode_New(length); if (w == NULL) return -1; ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-05-26 17:43 Message: Logged In: YES user_id=89016 The change to PyUnicode_Resize() should be reverted (or done in a way that doesn't lead to bugs). Unfortunately I don't have a Windows where I can test the patch, so I'm unassigning the bug. You should probably find someone on python-dev with a multibyte version of Windows to look at the patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:06 Message: Logged In: YES user_id=1200846 >PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, >but probably I'll fix it too. Done. Attached as "mbcs_win64_support.patch". Now, total summary... - MBCS decoder and encoder now supports 64bit Py_ssize_t environment. (I don't have such machine, but I checked routine by defining NEED_RETRY and redefining INT_MAX as 2, 3, 4) - Fixed a bug of MBCS incremental decoder which was originaly reported by me. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-24 22:18 Message: Logged In: YES user_id=1200846 I updated the patch. - PyUnicode_DecodeMBCS now supports size >= INT_MAX. (I don't have machine to test such big string, but I have tested this routine replaced INT_MAX with 2 and 3) PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, but probably I'll fix it too. This patch includes Patch#1494487. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-02 13:40 Message: Logged In: YES user_id=1200846 I updated the patch. (I copy and pasted "int final = 0" from above code (ex: utf_16_ex_decode), maybe they also should be changed for consistency?) And one more thing, I noticed "errors" is ignored now. We can detect invalid character if we set MB_ERR_INVALID_CHARS flag when calling MultiByteToWideChar, but we cannot tell where is the position of invalid character, and MSDN saids this flag is available Win2000SP4 or later (I don't know why) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp So I didn't make the patch for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-25 19:22 Message: Logged In: YES user_id=89016 I think the default value for final in mbcs_decode() should be true, so that the stateless decoder detects incomplete byte sequences too. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-04-07 11:10 Message: Logged In: YES user_id=1200846 I have sent contributor form via postal mail. Probably you can get it after 10 days. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 10:16 Message: Logged In: YES user_id=1200846 You are right. I've updated the patch. (mbcs5.patch) >>> import codecs [20198 refs] >>> d = codecs.getincrementaldecoder("mbcs")() [20198 refs] >>> d.decode('\x82\xa0\x82') u'\u3042' [20198 refs] >>> d.decode('') u'' [20198 refs] >>> d.decode('', final=True) u'\x00' [20198 refs] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-27 18:06 Message: Logged In: YES user_id=89016 _buffer_decode() in the IncrementalDecoder ignores the final argument. IncrementalDecoder._buffer_decode() should pass on its final argument to _codecsmodules.c::mbcs_decode(), which should be extended to accept the final argument. Also PyUnicode_DecodeMBCSStateful() must handle consumed == NULL correctly (with your patch it drops trailing lead bytes even if consumed == NULL) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 09:41 Message: Logged In: YES user_id=1200846 I replaced tests. Probably this is better instead of comparing the two string generated by same decoder. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 07:44 Message: Logged In: YES user_id=1200846 My real name is Hirokazu Yamamoto. But sorry, I don't have FAX. (It's needed to send contributor form, isn't it?) I'll attach the patch updated for trunk. And I'll attach the tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-26 23:05 Message: Logged In: YES user_id=21627 I have reservations against this patch because of the quasi-anonymous nature of the submission. ocean-city, can you please state your real name? Would you also be willing to fill out a contributor form, as shown on http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-24 15:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-23 22:44 Message: Logged In: YES user_id=89016 This isn't a bugfix in the strictest sense, so IMHO this patch shouldn't go into 2.4. If the patch goes into 2.5, it would need the appropriate changes to encodings/mbcs.py (i.e. the IncrementalDecoder would have to be changed (inheriting from BufferedIncrementalDecoder). I realize that this patch might be hard to test, as results are dependent on locale. Nevertheless at least some tests would be good (even if they are only run or do something useful on a certain locale and are skipped otherwise). ocean-city, can you update the patch for the trunk and add tests? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-23 03:51 Message: Logged In: YES user_id=1200846 Hello. This is my final patch. (mbcs4.patch) - mbcs3a.patch: _mbsbtype depends on locale not system ANSI code page. so probably it's not good to use it with MultiByteToWideChar. - mbcs3b.patch: CharNext may cause buffer overflow. and this patch always calls CharPrev but it's not needed if string is not terminated with "potensial" lead byte. I hope this is stable enough to commit on repositry. Thank you. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 15:36 Message: Logged In: YES user_id=1200846 Sorry, I was stupid. MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp) saids, > IsDBCSLeadByte can only indicate a potential lead byte value. IsDBCSLeadByte was returning 1 for some trail byte (ex: "?"[1]) The patch "mbcs3a.patch" worked for me, but _mbsbtype is probably compiler specific. Is that OK? The patch "mbcs3b.patch" also worked for me and it only uses Win32API, but I don't have enough faith on this implementation... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:31 Message: Logged In: YES user_id=1200846 Sorry, I found problem when tried more long text file... Please wait. I'll investigate more intensibly. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 11:13 Message: Logged In: YES user_id=1200846 Thank you for reply. How about this? (I'm a newbie, I hope this is right tex format but... can you confirm this? I created this patch by copy & paste from PyUnicode_DecodeUTF16Stateful and some modification) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:12 Message: Logged In: YES user_id=38388 One more nit: the doc patch is missing. Please add a patch for the API docs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 10:11 Message: Logged In: YES user_id=38388 As I understand your comment, the mbcs codec will have a problem if the input string terminates with a lead byte. Could you add a comment regarding this to the patch ?! I can't test the patch, since I don't have a Japanese Windows to check on, but from looking at the patch, it seems OK. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 08:42 Message: Logged In: YES user_id=1200846 I forgot to mention this. "mbcs.patch" is for release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Aug 2 19:33:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 10:33:13 -0700 Subject: [Patches] [ python-Patches-1533336 ] Remove mentions of "PyUnit" from unittest docs Message-ID: Patches item #1533336, was opened at 2006-08-02 13:33 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=1533336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove mentions of "PyUnit" from unittest docs Initial Comment: The attached removes the mentions of unittest's old name, PyUnit, from the library's documentation. In particular, it removes a link to PyUnit's old website, pyunit.sourceforge.net, which has seen all of two updates since 2001. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533336&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:15:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:15:48 -0700 Subject: [Patches] [ python-Patches-1532975 ] Replace the ctypes internal '_as_parameter_' mechanism Message-ID: Patches item #1532975, was opened at 2006-08-02 01:57 Message generated for change (Comment added) made by shane_holloway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Replace the ctypes internal '_as_parameter_' mechanism Initial Comment: This patch removes the '_as_parameter_' public attribute of ctypes instances, and replaces the mechanism by an internal one. This mechanism is used to convert a ctypes instance to an (internal) PyCArgObject instance which can directly by used as an argument in a C function call. With this patch, a C function pointer which does create the PyCArgObject instance is stored in the type dictionary (an StgDict instance). This does speed up foreign function calls with one ctypes argument by about 20%, but more important, it will allow to fix the '_as_parameter_' mechanism, which is documented in [1], so that it actually will work as describes, even for functions that have 'argtypes' set. [1] http://docs.python.org/dev/lib/ctypes-calling-functions-with-own-custom-data-types.html ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2006-08-02 16:15 Message: Logged In: YES user_id=283742 This patch enables bug fix for the _as_parameter_ mechanism. Please see http://python.org/sf/1533481. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:42:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:42:06 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2006-08-03 00:42 Message: Logged In: YES user_id=226443 I've relicensed the module and hereby withdraw it from consideration. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=226443 Another reference to DESKTOP_LAUNCH: http://www.openoffice.org/issues/show_bug.cgi?id=37708 ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-10-01 01:54 Message: Logged In: YES user_id=226443 I've removed the attachments from this item and uploaded a proper package to PyPI: http://www.python.org/pypi/desktop I still think it's worth keeping this item open, even though it was never really a patch as such, because I still believe the need is there for the standard library. Moreover, I've licensed the code according to the PSF criteria in order to satisfy that eventual objective. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 12:50 Message: Logged In: YES user_id=261020 Mike: I'm unpersuaded, but I've nothing to add to what I've already said, so I'll shut up now :-) ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-27 12:07 Message: Logged In: YES user_id=226443 Well, the latest attachment (the first in the list) goes some way towards providing user override support. I've since posted to the xdg mailing list asking for clarification about environment variables. As for the code, I've now changed the way the environment variable is used - it must be a shell-quoted command plus optional arguments. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-27 03:14 Message: Logged In: YES user_id=93910 I purposely avoided dealing with the "better off using os.system" before, because I didn't think it was relevant. Since you seem to think it's right, let's deal with it. First of all, the code isn't that simple. You want a convention for your environment variable that's flexible enough to deal with the three cases (kde, gnome and OS X) we already have. Just tossing a string to Popen won't cut it. The split() done by the current implementation is problematical - OS X at the very least comes with standard directories with spaces in their names. I'm not proposing a solution to that here - just pointing out the problem. You're advocating that, instead of putting this functionality in desktop, we leave it up to every application writer to write it. That means - at the very least - that every application writer now has to write if os.environ.has_key("DESKTOP_LAUNCH"): else: desktop.open(filename) rather than simply doing: desktop.open(filename) It also means that every application writer has to decide how they're going to deal with possible spaces in the file name in the environment variable, or if they are at all. And they also get to decide which of the various proposed environment variable names they want to use. If the user is lucky, they won't have two applications that use the same name with different conventions. If not, well, that would just suck. Second, if another a standard does emerge, you can fix all the applications by fixing *one* file in stdlib. Better yet, ithe fix can be transitioned in smoothly for all applications by working with that one file. Basically, *not* providing this hook is simply poor software engineering - it makes things harder on the developers, harder on the users, and harder on the maintainers in the future. While not wanting to push forward standards may be a good thing, it's certainly not a reason for doing a wrong thing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 02:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 15:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 04:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Thu Aug 3 01:35:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 16:35:27 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23: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=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Thu Aug 3 01:36:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 16:36:29 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23:35 Message generated for change (Settings changed) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Thu Aug 3 02:16:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 17:16:30 -0700 Subject: [Patches] [ python-Patches-1521882 ] Give Cookie.py its own _idmap Message-ID: Patches item #1521882, was opened at 2006-07-13 15:09 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521882&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Give Cookie.py its own _idmap Initial Comment: Currently, Lib/Cookie.py relies on being able to import _idmap -- an internal implementation detail -- from string.py. Given that string.py includes a comment "Note that Cookie.py bogusly uses _idmap :(", it seems this might be something worth fixing. The attached patch resolves this issue by having Cookie.py generate its own copy of _idmap. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-03 00:16 Message: Logged In: YES user_id=1126061 For what my opinion's worth, this patch looks fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521882&group_id=5470 From noreply at sourceforge.net Thu Aug 3 03:48:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 18:48:31 -0700 Subject: [Patches] [ python-Patches-1533336 ] Remove mentions of "PyUnit" from unittest docs Message-ID: Patches item #1533336, was opened at 2006-08-02 13:33 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533336&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove mentions of "PyUnit" from unittest docs Initial Comment: The attached removes the mentions of unittest's old name, PyUnit, from the library's documentation. In particular, it removes a link to PyUnit's old website, pyunit.sourceforge.net, which has seen all of two updates since 2001. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-08-02 21:48 Message: Logged In: YES user_id=1344176 I'm withdrawing this patch. I'll incorporate this into a larger cleanup of unittest's documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533336&group_id=5470 From noreply at sourceforge.net Thu Aug 3 10:51:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 01:51:05 -0700 Subject: [Patches] [ python-Patches-1532975 ] Replace the ctypes internal '_as_parameter_' mechanism Message-ID: Patches item #1532975, was opened at 2006-08-02 09:57 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Replace the ctypes internal '_as_parameter_' mechanism Initial Comment: This patch removes the '_as_parameter_' public attribute of ctypes instances, and replaces the mechanism by an internal one. This mechanism is used to convert a ctypes instance to an (internal) PyCArgObject instance which can directly by used as an argument in a C function call. With this patch, a C function pointer which does create the PyCArgObject instance is stored in the type dictionary (an StgDict instance). This does speed up foreign function calls with one ctypes argument by about 20%, but more important, it will allow to fix the '_as_parameter_' mechanism, which is documented in [1], so that it actually will work as describes, even for functions that have 'argtypes' set. [1] http://docs.python.org/dev/lib/ctypes-calling-functions-with-own-custom-data-types.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-03 10:51 Message: Logged In: YES user_id=11105 The previous patch was against the ctypes repository. I've deleted this patch and attached a new one against the Python svn trunk. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2006-08-03 00:15 Message: Logged In: YES user_id=283742 This patch enables bug fix for the _as_parameter_ mechanism. Please see http://python.org/sf/1533481. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:32:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:32:38 -0700 Subject: [Patches] [ python-Patches-1533909 ] Let timeit accept functions Message-ID: Patches item #1533909, was opened at 2006-08-03 10: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=1533909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Let timeit accept functions Initial Comment: I see that there is a history of proposed (and rejected) patches to allow timeit to see various module global namespaces, etc. But I'm surprised that no one has proposed the obvious functional solution: allow the arguments (particularly 'stmt') to be functions that get called, instead of strings that get parsed and executed. This does increase the measurement overhead slightly, adding in the function call, but in many cases it is far more useful within scripts. To time some part of the code, you can replace a function call 'foo()' with 'timeit.Timer(foo).timeit()'. I also propose helper functions for use within scripts: timeit.timeit(...) is shorthand for timeit.Timer(...).timeit(...), and timeit.repeat(...) is shorthand for timeit.Timer(...).repeat(...). Now you can replace a function call 'foo()' with 'timeit.timeit(foo)', e.g., 'print "foo takes", timeit.timeit(foo), "seconds"'. Attached is a simple patch implementing both of these changes. Documentation would need updating too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533909&group_id=5470 From noreply at sourceforge.net Thu Aug 3 19:59:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 10:59:29 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 13:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Iain Lowe (ilowe54) Assigned to: Nobody/Anonymous (nobody) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:03:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:03:38 -0700 Subject: [Patches] [ python-Patches-1496952 ] Convert Tkinter to METH_VARARGS style Message-ID: Patches item #1496952, was opened at 2006-05-29 14:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1496952&group_id=5470 Please note that this 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: Later Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: Convert Tkinter to METH_VARARGS style Initial Comment: Patch attached. Martin, as the maintainer please check. I also changed some PyTuple_Size and PyTuple_GetItem to the corresponding macros when tupleness is guaranteed. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 18:03 Message: Logged In: YES user_id=849994 This can be addressed when METH_OLDARGS is officially deprecated. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-04 08:19 Message: Logged In: YES user_id=21627 The patch is wrong: .call() might get called with a single argument which is a tuple; this should be treated the same as if multiple arguments had been passed. Please leave out the unrelated changes to the tuple API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1496952&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:06:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:06:57 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 17:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Iain Lowe (ilowe54) >Assigned to: A.M. Kuchling (akuchling) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 18:06 Message: Logged In: YES user_id=849994 The patch is wrong, format() did never allow anything other than a single %char. (The difference is that it's now documented). A little bit more should be written about the two new functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:11:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:11:01 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 13:59 Message generated for change (Comment added) made by ilowe54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Iain Lowe (ilowe54) Assigned to: A.M. Kuchling (akuchling) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- >Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:11 Message: Logged In: YES user_id=103438 I'm able to pass a string in 2.4; what am I doing wrong? I'll update the patch with more details on the other two functions. Python 2.4.2 (#1, Oct 16 2005, 05:52:17) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.format('This is my %dnd test', 2) 'This is my 2nd test' >>> ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 14:06 Message: Logged In: YES user_id=849994 The patch is wrong, format() did never allow anything other than a single %char. (The difference is that it's now documented). A little bit more should be written about the two new functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:12:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:12:37 -0700 Subject: [Patches] [ python-Patches-1533909 ] Let timeit accept functions Message-ID: Patches item #1533909, was opened at 2006-08-03 14:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Let timeit accept functions Initial Comment: I see that there is a history of proposed (and rejected) patches to allow timeit to see various module global namespaces, etc. But I'm surprised that no one has proposed the obvious functional solution: allow the arguments (particularly 'stmt') to be functions that get called, instead of strings that get parsed and executed. This does increase the measurement overhead slightly, adding in the function call, but in many cases it is far more useful within scripts. To time some part of the code, you can replace a function call 'foo()' with 'timeit.Timer(foo).timeit()'. I also propose helper functions for use within scripts: timeit.timeit(...) is shorthand for timeit.Timer(...).timeit(...), and timeit.repeat(...) is shorthand for timeit.Timer(...).repeat(...). Now you can replace a function call 'foo()' with 'timeit.timeit(foo)', e.g., 'print "foo takes", timeit.timeit(foo), "seconds"'. Attached is a simple patch implementing both of these changes. Documentation would need updating too. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 18:12 Message: Logged In: YES user_id=849994 Please use four-space indents when contributing library code. Perhaps unicode "stmt" arguments should also be allowed. Perhaps other arguments should be checked with callable() to exclude lists or something like that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533909&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:14:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:14:26 -0700 Subject: [Patches] [ python-Patches-1528167 ] Tweak to make string.Templates more customizable Message-ID: Patches item #1528167, was opened at 2006-07-25 00:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Tweak to make string.Templates more customizable Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-03 13:14 Message: Logged In: YES user_id=80475 The replacement of _multimap is a semantic change. Formerly, a dictionary passed in as a positional argument is left unmolested; now, it is mutated to reflect kwds. Also, the _multimap setup is an O(1) step while the update() approach is O(n). Also, the current implementation only requires the positional argument to support __getitem__(); now, it requires a more fully compliant duck (one that provides an .update() method). - mapping = _multimap(kws, args[0]) + mapping = args[0] + mapping.update(kws) Current behavior: >>> t = Template('the $speed brown') >>> d = dict(speed='quick') >>> t.safe_substitute(d, speed='slow') 'the slow brown' >>> d {'speed': 'quick'} After the patch, it returns {'speed': 'slow'}. Likewise the following now works, but would fail after the patch: >>> t = Template('the $speed brown') >>> class D: def __getitem__(self, key): return 'quick' >>> t.safe_substitute(D(), speed='slow') 'the slow brown' The whole approach is misguided, and the use case itself is suspect. If some change is warranted, consider a cleaner, more general-purpose solution like having an optional key= argument to the Template constructor for pre-processing keys: >>> t = Template('the $speed brown', key=str.lower) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 21:12 Message: Logged In: YES user_id=12800 Looks good to me. Remind us when we fork the trunk. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:07 Message: Logged In: YES user_id=340931 Ok, here it is! I added a test but wasn't sure this warranted a doc change. Cf.: http://docs.python.org/dev/lib/node40.html ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 08:24 Message: Logged In: YES user_id=12800 Yes, that would be much more acceptable! ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 08:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 22:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 18:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 17:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 13:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 13:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 14:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:17:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:17:15 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 13:59 Message generated for change (Comment added) made by ilowe54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Iain Lowe (ilowe54) Assigned to: A.M. Kuchling (akuchling) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- >Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:17 Message: Logged In: YES user_id=103438 Updated the patch to add some more details on format_string and currency functions. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:11 Message: Logged In: YES user_id=103438 I'm able to pass a string in 2.4; what am I doing wrong? I'll update the patch with more details on the other two functions. Python 2.4.2 (#1, Oct 16 2005, 05:52:17) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.format('This is my %dnd test', 2) 'This is my 2nd test' >>> ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 14:06 Message: Logged In: YES user_id=849994 The patch is wrong, format() did never allow anything other than a single %char. (The difference is that it's now documented). A little bit more should be written about the two new functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:19:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:19:47 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 17:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Iain Lowe (ilowe54) Assigned to: A.M. Kuchling (akuchling) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 18:19 Message: Logged In: YES user_id=849994 Okay, that works. But look at >>> locale.format('test %0.2f %0.2f', (2.0, 2.0)) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 143, in format raise Error, "Too many decimal points in result string" locale.Error: Too many decimal points in result string or >>> locale.format('%i .test', 0) '0 ,test' (in a German locale). So the only thing format() did do without unwanted side-effects was and is to convert exactly one %char code. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 18:17 Message: Logged In: YES user_id=103438 Updated the patch to add some more details on format_string and currency functions. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 18:11 Message: Logged In: YES user_id=103438 I'm able to pass a string in 2.4; what am I doing wrong? I'll update the patch with more details on the other two functions. Python 2.4.2 (#1, Oct 16 2005, 05:52:17) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.format('This is my %dnd test', 2) 'This is my 2nd test' >>> ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 18:06 Message: Logged In: YES user_id=849994 The patch is wrong, format() did never allow anything other than a single %char. (The difference is that it's now documented). A little bit more should be written about the two new functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:30:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:30:15 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 13:59 Message generated for change (Comment added) made by ilowe54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Iain Lowe (ilowe54) Assigned to: A.M. Kuchling (akuchling) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- >Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:30 Message: Logged In: YES user_id=103438 Updated description of changes to format ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 14:19 Message: Logged In: YES user_id=849994 Okay, that works. But look at >>> locale.format('test %0.2f %0.2f', (2.0, 2.0)) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 143, in format raise Error, "Too many decimal points in result string" locale.Error: Too many decimal points in result string or >>> locale.format('%i .test', 0) '0 ,test' (in a German locale). So the only thing format() did do without unwanted side-effects was and is to convert exactly one %char code. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:17 Message: Logged In: YES user_id=103438 Updated the patch to add some more details on format_string and currency functions. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:11 Message: Logged In: YES user_id=103438 I'm able to pass a string in 2.4; what am I doing wrong? I'll update the patch with more details on the other two functions. Python 2.4.2 (#1, Oct 16 2005, 05:52:17) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.format('This is my %dnd test', 2) 'This is my 2nd test' >>> ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 14:06 Message: Logged In: YES user_id=849994 The patch is wrong, format() did never allow anything other than a single %char. (The difference is that it's now documented). A little bit more should be written about the two new functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 3 20:36:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 11:36:46 -0700 Subject: [Patches] [ python-Patches-1534048 ] Typo in weakref error message Message-ID: Patches item #1534048, was opened at 2006-08-03 14: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=1534048&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Tur Lesniewski-Laas (ctl) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in weakref error message Initial Comment: An error message in Objects/typeobject.c mistakenly refers to __weaklist__, which does not exist. The intent was most likely __weakref__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534048&group_id=5470 From noreply at sourceforge.net Thu Aug 3 21:51:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 12:51:23 -0700 Subject: [Patches] [ python-Patches-1534084 ] Fix code generation bug in 'compiler' package Message-ID: Patches item #1534084, was opened at 2006-08-03 19:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 Please note that this 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: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neal Norwitz (nnorwitz) Summary: Fix code generation bug in 'compiler' package Initial Comment: The compiler package generates invalid code for nested functions (a BUILD_TUPLE opcode is now required). Obviously we need better tests for the package. It would be really nice if this could get fixed before 2.5 is released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 From noreply at sourceforge.net Fri Aug 4 01:52:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 16:52:36 -0700 Subject: [Patches] [ python-Patches-1528167 ] Tweak to make string.Templates more customizable Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Tweak to make string.Templates more customizable Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-08-03 19:52 Message: Logged In: YES user_id=340931 Raymond, Thanks for the attention to detail. But could you help me understand what it means that "the whole approach is misguided, and the use case itself is suspect[?]" The customization use case? The approach to customization via the mapping argument? In other words, I understood the mapping argument to already be a customization mechanism; otherwise, the methods could use kws only. So wouldn't a 'key' argument be *more* complicated, introducing additional customization semantics instead of working with what's already there? My concern, though, is that by using _multimap instead of update, we limit the customizations one may perform from the outside. Why this limitation? Performance? Ok. So then it's a matter of adjudicating a performance/feature trade-off? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-03 14:14 Message: Logged In: YES user_id=80475 The replacement of _multimap is a semantic change. Formerly, a dictionary passed in as a positional argument is left unmolested; now, it is mutated to reflect kwds. Also, the _multimap setup is an O(1) step while the update() approach is O(n). Also, the current implementation only requires the positional argument to support __getitem__(); now, it requires a more fully compliant duck (one that provides an .update() method). - mapping = _multimap(kws, args[0]) + mapping = args[0] + mapping.update(kws) Current behavior: >>> t = Template('the $speed brown') >>> d = dict(speed='quick') >>> t.safe_substitute(d, speed='slow') 'the slow brown' >>> d {'speed': 'quick'} After the patch, it returns {'speed': 'slow'}. Likewise the following now works, but would fail after the patch: >>> t = Template('the $speed brown') >>> class D: def __getitem__(self, key): return 'quick' >>> t.safe_substitute(D(), speed='slow') 'the slow brown' The whole approach is misguided, and the use case itself is suspect. If some change is warranted, consider a cleaner, more general-purpose solution like having an optional key= argument to the Template constructor for pre-processing keys: >>> t = Template('the $speed brown', key=str.lower) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 22:12 Message: Logged In: YES user_id=12800 Looks good to me. Remind us when we fork the trunk. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 10:07 Message: Logged In: YES user_id=340931 Ok, here it is! I added a test but wasn't sure this warranted a doc change. Cf.: http://docs.python.org/dev/lib/node40.html ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-01 09:24 Message: Logged In: YES user_id=12800 Yes, that would be much more acceptable! ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 09:21 Message: Logged In: YES user_id=340931 Thanks for your responses, all. > Is there a reason why the existing mechanisms are > insufficient? The problem is kws: you can't customize it from the outside like you can the mapping argument. If we replaced _multimap with mapping.update(kws), then we'd have our hook and I think I'd be satisfied. Would you be any more psyched about that patch? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-31 23:56 Message: Logged In: YES user_id=12800 I'm not psyched about the patch. First, I've always thought that case insensitivity ought to be handled by the mapping from which the keys are being extracted and by setting the idpattern. Second, I definitely don't like adding the case_sensitive argument to substitute() and safe_substitute(). Because it lives in the same namespace as kws it makes for icky rules on resolving any conflicts. Is there a reason why the existing mechanisms are insufficient? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-31 19:12 Message: Logged In: YES user_id=80475 Barry, is this something you want or is it at odds with the notion of "simplified templating"? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-31 18:32 Message: Logged In: YES user_id=849994 The patch looks very thorough and complete, I will try to look into it after 2.5 is out. Don't let that prevent you reviewing 5 patches, Chad ;-) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Fri Aug 4 05:45:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 20:45:50 -0700 Subject: [Patches] [ python-Patches-1534048 ] Typo in weakref error message Message-ID: Patches item #1534048, was opened at 2006-08-03 11:36 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534048&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Tur Lesniewski-Laas (ctl) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in weakref error message Initial Comment: An error message in Objects/typeobject.c mistakenly refers to __weaklist__, which does not exist. The intent was most likely __weakref__. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 20:45 Message: Logged In: YES user_id=33168 See bug 1531003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534048&group_id=5470 From noreply at sourceforge.net Fri Aug 4 05:53:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 20:53:51 -0700 Subject: [Patches] [ python-Patches-1534084 ] Fix code generation bug in 'compiler' package Message-ID: Patches item #1534084, was opened at 2006-08-03 12:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 Please note that this 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: 7 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: Fix code generation bug in 'compiler' package Initial Comment: The compiler package generates invalid code for nested functions (a BUILD_TUPLE opcode is now required). Obviously we need better tests for the package. It would be really nice if this could get fixed before 2.5 is released. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 20:53 Message: Logged In: YES user_id=33168 Good catch! It's always good to see bug fixes which remove code. :-) Please checkin once the the code is unfrozen. It would be good to mention this patch # in the NEWS entry. This is also a backport candidate, isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 From noreply at sourceforge.net Fri Aug 4 05:54:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 20:54:17 -0700 Subject: [Patches] [ python-Patches-1534084 ] Fix code generation bug in 'compiler' package Message-ID: Patches item #1534084, was opened at 2006-08-03 12:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 Please note that this 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: 9 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Fix code generation bug in 'compiler' package Initial Comment: The compiler package generates invalid code for nested functions (a BUILD_TUPLE opcode is now required). Obviously we need better tests for the package. It would be really nice if this could get fixed before 2.5 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 20:53 Message: Logged In: YES user_id=33168 Good catch! It's always good to see bug fixes which remove code. :-) Please checkin once the the code is unfrozen. It would be good to mention this patch # in the NEWS entry. This is also a backport candidate, isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 From noreply at sourceforge.net Fri Aug 4 07:18:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:18:44 -0700 Subject: [Patches] [ python-Patches-1534048 ] Typo in weakref error message Message-ID: Patches item #1534048, was opened at 2006-08-03 14:36 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534048&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christopher Tur Lesniewski-Laas (ctl) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Typo in weakref error message Initial Comment: An error message in Objects/typeobject.c mistakenly refers to __weaklist__, which does not exist. The intent was most likely __weakref__. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-08-04 01:18 Message: Logged In: YES user_id=3066 Committed for the Python trunk (2.5; revision 51084), and the release24-maint branch (2.4.4; revision 51083). Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 23:45 Message: Logged In: YES user_id=33168 See bug 1531003 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534048&group_id=5470 From noreply at sourceforge.net Fri Aug 4 07:29:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:29:16 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-28 20:47 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this 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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-01 08:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 11:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 09:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 06:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-28 21:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Fri Aug 4 07:57:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:57:06 -0700 Subject: [Patches] [ python-Patches-1534084 ] Fix code generation bug in 'compiler' package Message-ID: Patches item #1534084, was opened at 2006-08-03 19:51 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 Please note that this 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: 9 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Fix code generation bug in 'compiler' package Initial Comment: The compiler package generates invalid code for nested functions (a BUILD_TUPLE opcode is now required). Obviously we need better tests for the package. It would be really nice if this could get fixed before 2.5 is released. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2006-08-04 05:57 Message: Logged In: YES user_id=35752 No, it's not a backport candidate. During the 2.5 development cycle I changed the way the MAKE_CLOSURE opcode worked. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 03:53 Message: Logged In: YES user_id=33168 Good catch! It's always good to see bug fixes which remove code. :-) Please checkin once the the code is unfrozen. It would be good to mention this patch # in the NEWS entry. This is also a backport candidate, isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 From noreply at sourceforge.net Fri Aug 4 11:19:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 02:19:23 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 17:39 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this 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: 2 Submitted By: Collin Winter (collinwinter) >Assigned to: Neal Norwitz (nnorwitz) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-08-04 10:19 Message: Logged In: YES user_id=6656 I agree with arigo. Assigning to Neal so he can see this and get it off his "things to do for 2.5" list. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-25 19:08 Message: Logged In: YES user_id=4771 This patch is pointless. I recommend rejecting it. The crashers/gc_inspection.py was just one example among many of crashing Python with gc.get_referrers(). I don't see why we should care to fix just this specific way. What would be needed is a complete review, possibly with an API change to decouple object creation and GC registration, and appropriate documentation for extension module writers. I don't think it's likely to happen though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 07:28 Message: Logged In: YES user_id=33168 Note that the declaration of item needs to be moved to the top of the scope so it can compile with C89. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-05 23:31 Message: Logged In: YES user_id=80475 Crashers based on gc.get_referrers() should not be considered real bugs. It is certainly not worth complexifying the code or slowing it down just to preclude these little perverse safe-cracking exercises. Also, it is not worth the risk of introducing a real bug when the code was working fine. That being said, if the code is genuinely defective and has potential to cause real-world problems, then it should be fixed. I would think that if there were a long- standing problem with tuples, it would have manifested itself long ago. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-05 18:36 Message: Logged In: YES user_id=1344176 The improve_gc_inspection.patch file has been superseded by a patch attached to bug #1517663. The bug details another interpreter crash in the same vein as the one fix in tuple() by this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Fri Aug 4 18:20:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 09:20:58 -0700 Subject: [Patches] [ python-Patches-1534084 ] Fix code generation bug in 'compiler' package Message-ID: Patches item #1534084, was opened at 2006-08-03 19:51 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 Please note that this 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: 9 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: Fix code generation bug in 'compiler' package Initial Comment: The compiler package generates invalid code for nested functions (a BUILD_TUPLE opcode is now required). Obviously we need better tests for the package. It would be really nice if this could get fixed before 2.5 is released. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2006-08-04 16:20 Message: Logged In: YES user_id=35752 Committed as revision 51109. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-08-04 05:57 Message: Logged In: YES user_id=35752 No, it's not a backport candidate. During the 2.5 development cycle I changed the way the MAKE_CLOSURE opcode worked. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 03:53 Message: Logged In: YES user_id=33168 Good catch! It's always good to see bug fixes which remove code. :-) Please checkin once the the code is unfrozen. It would be good to mention this patch # in the NEWS entry. This is also a backport candidate, isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534084&group_id=5470 From noreply at sourceforge.net Sat Aug 5 06:23:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 21:23:29 -0700 Subject: [Patches] [ python-Patches-1534922 ] Cleanup/error-correction for unittest's docs Message-ID: Patches item #1534922, was opened at 2006-08-05 00:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534922&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Cleanup/error-correction for unittest's docs Initial Comment: The following patch, in addition to widespread typo and grammar corrections and style improvements, fixes the following errors/irritations: * Removes a link to the PyUnit website (pyunit.sf.net) and replaces use of the PyUnit name with unittest. The module has not been known by this name for years. * TextTestRunner is documented varyingly as printing to stdout and stderr; the latter is correct. This is now fixed. * Several usages of the deprecated makeSuite() function have been replaced with TestLoader()-based examples. * One needlessly-complex TestSuite construction example has been simplified to something understandable. * It is stated that classes that implement TestCase's interface can be used with unittest, even if they do not subclass TestCase. This is false, contradicting several other lines of documentation. Moreover, it does not reflect reality: unittest relies heavily on inheritance from TestCase to determine what is and what is not a test case. * It has now been made explicit which methods TestSuite shares with TestCase. Previously, this had been left as an exercise for the reader. * TestLoader.loadTestsFromName() was not documented as being able to handle a name that resolves to a TestSuite. It can, and this capability is now documented. * The documentation implied that TestLoader.sortTestMethodsUsing affects only TestLoader.getTestCaseNames(). This is inaccurate; it is now explicit that it also affects all TestLoader.loadTestsFrom*() methods. * Make it explicit that TestLoader.suiteClass and TestLoader.testMethodPrefix affect getTestCaseNames() and all loadTestsFrom*() methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534922&group_id=5470 From noreply at sourceforge.net Sat Aug 5 08:11:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 23:11:15 -0700 Subject: [Patches] [ python-Patches-1534922 ] Cleanup/error-correction for unittest's docs Message-ID: Patches item #1534922, was opened at 2006-08-05 04:23 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534922&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Cleanup/error-correction for unittest's docs Initial Comment: The following patch, in addition to widespread typo and grammar corrections and style improvements, fixes the following errors/irritations: * Removes a link to the PyUnit website (pyunit.sf.net) and replaces use of the PyUnit name with unittest. The module has not been known by this name for years. * TextTestRunner is documented varyingly as printing to stdout and stderr; the latter is correct. This is now fixed. * Several usages of the deprecated makeSuite() function have been replaced with TestLoader()-based examples. * One needlessly-complex TestSuite construction example has been simplified to something understandable. * It is stated that classes that implement TestCase's interface can be used with unittest, even if they do not subclass TestCase. This is false, contradicting several other lines of documentation. Moreover, it does not reflect reality: unittest relies heavily on inheritance from TestCase to determine what is and what is not a test case. * It has now been made explicit which methods TestSuite shares with TestCase. Previously, this had been left as an exercise for the reader. * TestLoader.loadTestsFromName() was not documented as being able to handle a name that resolves to a TestSuite. It can, and this capability is now documented. * The documentation implied that TestLoader.sortTestMethodsUsing affects only TestLoader.getTestCaseNames(). This is inaccurate; it is now explicit that it also affects all TestLoader.loadTestsFrom*() methods. * Make it explicit that TestLoader.suiteClass and TestLoader.testMethodPrefix affect getTestCaseNames() and all loadTestsFrom*() methods. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-05 06:11 Message: Logged In: YES user_id=849994 Thanks for the patch, I committed it almost unchanged as rev. 51123. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534922&group_id=5470 From noreply at sourceforge.net Sat Aug 5 17:10:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 08:10:33 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 01:10 Message: Logged In: YES user_id=1038590 Added version 4 of the patch. Changes: - is_index is now type_err, with the logical sense inverted and corresponding changes made to other parts of the patch (I didn't use type_error because that would have caused a name clash inside abstract.c) - for consistency in terminology, the internal function used for long conversion is now _PyLong_AsClippedSsize_t to match the PyNumber function, and the output variable used to report clipping is named clipped - an error message from _PyEval_SliceIndex had changed gratuitously, so I restored the original message. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-02 01:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 04:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-30 02:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sun Aug 6 02:21:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 17:21:59 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this 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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 10:21 Message: Logged In: YES user_id=1038590 Put the priority back to 9 (I accidentally changed it back to 7 when I attached the new patch) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 01:10 Message: Logged In: YES user_id=1038590 Added version 4 of the patch. Changes: - is_index is now type_err, with the logical sense inverted and corresponding changes made to other parts of the patch (I didn't use type_error because that would have caused a name clash inside abstract.c) - for consistency in terminology, the internal function used for long conversion is now _PyLong_AsClippedSsize_t to match the PyNumber function, and the output variable used to report clipping is named clipped - an error message from _PyEval_SliceIndex had changed gratuitously, so I restored the original message. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-02 01:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 04:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-30 02:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sun Aug 6 21:32:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 12:32:29 -0700 Subject: [Patches] [ python-Patches-1535500 ] writelines() in bz2 module does not raise check for errors Message-ID: Patches item #1535500, was opened at 2006-08-06 21: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=1535500&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lawrence Oluyede (rhymes) Assigned to: Nobody/Anonymous (nobody) Summary: writelines() in bz2 module does not raise check for errors Initial Comment: In the BZ2File object of bz2 module the writelines() method does not check its closed state before doing the actual work so its behavior it's different from write()'s behavior. See: >>> from bz2 import BZ2File >>> f = BZ2File("foo", "w") >>> f.close() >>> f.closed 1 >>> f.write("foobar") Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file >>> f.closed 1 >>> f.writelines(["foobar"]) Traceback (most recent call last): File "", line 1, in IOError: unknown IO error It also doesn't check if it can write for real: >>> from bz2 import BZ2File >>> f = BZ2File("foo", "r") >>> f.write("foobar") Traceback (most recent call last): File "", line 1, in IOError: file is not ready for writing >>> f.writelines(['foobar']) Traceback (most recent call last): File "", line 1, in RuntimeError: wrong sequence of bz2 library commands used ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535500&group_id=5470 From noreply at sourceforge.net Sun Aug 6 21:43:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 12:43:53 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 21:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From noreply at sourceforge.net Mon Aug 7 03:20:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 18:20:52 -0700 Subject: [Patches] [ python-Patches-1535659 ] NNTPS support in nntplib Message-ID: Patches item #1535659, was opened at 2006-08-06 21: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=1535659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Aurojit Panda (aurojit) Assigned to: Nobody/Anonymous (nobody) Summary: NNTPS support in nntplib Initial Comment: This patch adds SSL support for nntplib, since it really isn't that simple to just extend the class and add such support, and there are plenty of NNTP servers out there which can only be accessed over SSL. Should be backwards compatible with nntplib, and has been tested to be as such. Of course this library faces limitations on how well it can authenticate SSL certificates due to current limitations (as of 2.4) in socket.ssl, no new additions seem to have been made in 2.5, at least none are listed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535659&group_id=5470 From noreply at sourceforge.net Mon Aug 7 03:28:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 18:28:46 -0700 Subject: [Patches] [ python-Patches-1535659 ] NNTPS support in nntplib Message-ID: Patches item #1535659, was opened at 2006-08-06 21:20 Message generated for change (Settings changed) made by aurojit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535659&group_id=5470 Please note that this 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: 4 Submitted By: Aurojit Panda (aurojit) Assigned to: Nobody/Anonymous (nobody) Summary: NNTPS support in nntplib Initial Comment: This patch adds SSL support for nntplib, since it really isn't that simple to just extend the class and add such support, and there are plenty of NNTP servers out there which can only be accessed over SSL. Should be backwards compatible with nntplib, and has been tested to be as such. Of course this library faces limitations on how well it can authenticate SSL certificates due to current limitations (as of 2.4) in socket.ssl, no new additions seem to have been made in 2.5, at least none are listed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535659&group_id=5470 From noreply at sourceforge.net Mon Aug 7 17:22:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 08:22:33 -0700 Subject: [Patches] [ python-Patches-1536071 ] trace.py on win32 has problems with lowercase drive names Message-ID: Patches item #1536071, was opened at 2006-08-07 17:22 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=1536071&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adam Groszer (agroszer) Assigned to: Nobody/Anonymous (nobody) Summary: trace.py on win32 has problems with lowercase drive names Initial Comment: The following patch should solve it: --- svn-trace.py-46805 +++ U:\Python24\Lib\trace.py @@ -179,8 +177,12 @@ # looking in sys.path for the longest matching prefix. We'll # assume that the rest is the package name. + path = os.path.normcase(path) + longest = "" for dir in sys.path: + dir = os.path.normcase(dir) + if path.startswith(dir) and path[len(dir)] == os.path.sep: if len(dir) > len(longest): longest = dir ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536071&group_id=5470 From noreply at sourceforge.net Tue Aug 8 20:39:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 11:39:24 -0700 Subject: [Patches] [ python-Patches-1536908 ] Build ctypes on OpenBSD x86_64 Message-ID: Patches item #1536908, was opened at 2006-08-08 20:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Build ctypes on OpenBSD x86_64 Initial Comment: This patch from Damien Miller enables building ctypes on OpenBSD x86_64. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 From noreply at sourceforge.net Tue Aug 8 23:40:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 14:40:58 -0700 Subject: [Patches] [ python-Patches-1536908 ] Build ctypes on OpenBSD x86_64 Message-ID: Patches item #1536908, was opened at 2006-08-08 11:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: Build ctypes on OpenBSD x86_64 Initial Comment: This patch from Damien Miller enables building ctypes on OpenBSD x86_64. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-08 14:40 Message: Logged In: YES user_id=33168 Thomas, you can apply this if you want. Are you sure about the last bit about remove -fno-stack-protector though? That part seems a bit more dangerous, but I'll leave the decision up to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 From noreply at sourceforge.net Wed Aug 9 15:57:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 06:57:38 -0700 Subject: [Patches] [ python-Patches-1534027 ] Add notes on locale module changes to whatsnew25.tex Message-ID: Patches item #1534027, was opened at 2006-08-03 13:59 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Iain Lowe (ilowe54) Assigned to: A.M. Kuchling (akuchling) Summary: Add notes on locale module changes to whatsnew25.tex Initial Comment: This patch modifies the whatsnew25.tex to reflect changes to the locale module. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-09 09:57 Message: Logged In: YES user_id=11375 Applied in rev. 51169 with some markup and wording changes. Thanks! ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:30 Message: Logged In: YES user_id=103438 Updated description of changes to format ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 14:19 Message: Logged In: YES user_id=849994 Okay, that works. But look at >>> locale.format('test %0.2f %0.2f', (2.0, 2.0)) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 143, in format raise Error, "Too many decimal points in result string" locale.Error: Too many decimal points in result string or >>> locale.format('%i .test', 0) '0 ,test' (in a German locale). So the only thing format() did do without unwanted side-effects was and is to convert exactly one %char code. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:17 Message: Logged In: YES user_id=103438 Updated the patch to add some more details on format_string and currency functions. ---------------------------------------------------------------------- Comment By: Iain Lowe (ilowe54) Date: 2006-08-03 14:11 Message: Logged In: YES user_id=103438 I'm able to pass a string in 2.4; what am I doing wrong? I'll update the patch with more details on the other two functions. Python 2.4.2 (#1, Oct 16 2005, 05:52:17) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.format('This is my %dnd test', 2) 'This is my 2nd test' >>> ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 14:06 Message: Logged In: YES user_id=849994 The patch is wrong, format() did never allow anything other than a single %char. (The difference is that it's now documented). A little bit more should be written about the two new functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1534027&group_id=5470 From noreply at sourceforge.net Thu Aug 10 08:31:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 23:31:47 -0700 Subject: [Patches] [ python-Patches-1536908 ] Build ctypes on OpenBSD x86_64 Message-ID: Patches item #1536908, was opened at 2006-08-09 04:39 Message generated for change (Comment added) made by djmdjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Build ctypes on OpenBSD x86_64 Initial Comment: This patch from Damien Miller enables building ctypes on OpenBSD x86_64. ---------------------------------------------------------------------- Comment By: djmdjm (djmdjm) Date: 2006-08-10 16:31 Message: Logged In: YES user_id=1359232 I have tested the -fno-stack-protector on OpenBSD i386 and AMD64 - it passes regress tests on both. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-09 07:40 Message: Logged In: YES user_id=33168 Thomas, you can apply this if you want. Are you sure about the last bit about remove -fno-stack-protector though? That part seems a bit more dangerous, but I'll leave the decision up to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 From noreply at sourceforge.net Thu Aug 10 08:57:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 23:57:31 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-10 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=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: djmdjm (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Thu Aug 10 08:58:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 23:58:56 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-10 16:57 Message generated for change (Comment added) made by djmdjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: djmdjm (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: djmdjm (djmdjm) Date: 2006-08-10 16:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From G.S.-Design at t-online.de Thu Aug 10 11:26:32 2006 From: G.S.-Design at t-online.de (Hexer_eins@hotmail.de) Date: Thu, 10 Aug 2006 10:26:32 +0100 Subject: [Patches] You Can Be A Millionaire in 15 Minutes!! Message-ID: <1GB5ry-0Nji5Y0@fwd33.sul.t-online.de> You Can Be A Millionaire in 15 Minutes!! Turn $895 into $1M now. REAL opportunity. Not HYIP. Not MLM. No Selling. Tax Free. Has happened only 3 times before in our history, and is happening again RIGHT NOW! Banks and wealthy insiders are cashing in. You can too! VERY time sensitive. http://woelfchen.frankclick.hop.clickbank.net (No Spam, TKG ? 107/letter 4) If you never want Information from me, please remove this mail to me, and I delete your address. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20060810/6b3f5039/attachment.htm From noreply at sourceforge.net Thu Aug 10 16:10:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 07:10:15 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this 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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 00:10 Message: Logged In: YES user_id=1038590 Version 5 fast tracks builtin longs as well as ints ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 10:21 Message: Logged In: YES user_id=1038590 Put the priority back to 9 (I accidentally changed it back to 7 when I attached the new patch) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 01:10 Message: Logged In: YES user_id=1038590 Added version 4 of the patch. Changes: - is_index is now type_err, with the logical sense inverted and corresponding changes made to other parts of the patch (I didn't use type_error because that would have caused a name clash inside abstract.c) - for consistency in terminology, the internal function used for long conversion is now _PyLong_AsClippedSsize_t to match the PyNumber function, and the output variable used to report clipping is named clipped - an error message from _PyEval_SliceIndex had changed gratuitously, so I restored the original message. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-02 01:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 04:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-30 02:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Thu Aug 10 19:14:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 10:14:32 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 12:07 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this 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: 6 Submitted By: Tal Einat (taleinat) >Assigned to: Kurt B. Kaiser (kbk) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-10 13:14 Message: Logged In: YES user_id=149084 2.5b3 Rev 51189. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-30 08:06 Message: Logged In: YES user_id=1330769 I uploaded an update (another patch, apply after applying the first one), this fixes the behavior a bit. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-27 16:48 Message: Logged In: YES user_id=1330769 Bah, sorry for forgetting to post the file... It really was getting late that night :P ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 16:30 Message: Logged In: YES user_id=149084 Well, once you get it throughly tested, please attach the patch so I can look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Fri Aug 11 12:44:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 03:44:15 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-28 21:47 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this 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: 9 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-08-11 04:44 Message: Logged In: YES user_id=5296 I'm attaching a patch that fixes the problem using a more traditional C-API. Their are still 3 new C-API calls --- 1 is actually a macro * PyIndex_Check(obj) * PyNumber_Index(obj) --- is to nb_index as PyNumber_Int is to nb_int * PyNumber_AsSsize_t(obj, err) --- the second argument allows specifying the error when conversion to Pyssize_t raises an Overflow. If err == NULL, the value is clipped instead of raising any error. OverflowError and IndexError are the two errors used in Python itself and the standard library. * I kept the same unit-tests from Nick except that subclasses for integers are allowed as slice indices as this does not cause recursion. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-10 08:10 Message: Logged In: YES user_id=1038590 Version 5 fast tracks builtin longs as well as ints ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-05 18:21 Message: Logged In: YES user_id=1038590 Put the priority back to 9 (I accidentally changed it back to 7 when I attached the new patch) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-05 09:10 Message: Logged In: YES user_id=1038590 Added version 4 of the patch. Changes: - is_index is now type_err, with the logical sense inverted and corresponding changes made to other parts of the patch (I didn't use type_error because that would have caused a name clash inside abstract.c) - for consistency in terminology, the internal function used for long conversion is now _PyLong_AsClippedSsize_t to match the PyNumber function, and the output variable used to report clipping is named clipped - an error message from _PyEval_SliceIndex had changed gratuitously, so I restored the original message. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-01 09:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 12:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 10:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 07:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-28 22:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Fri Aug 11 12:51:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 03:51:34 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 04:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Travis Oliphant (teoliphant) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Fri Aug 11 12:52:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 03:52:05 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 04:51 Message generated for change (Settings changed) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) >Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Fri Aug 11 13:42:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 04:42:25 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this 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: Rejected >Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 21:42 Message: Logged In: YES user_id=1038590 I'm withdrawing this in favour of Travis's patch #1538606 - it's much more in line with the idioms used in other parts of the C API. It isn't worth messing up the API just to avoid checking for the existing of the nb_index slot twice. With Travis's patch, it's still straightforward for extension modules to do their own overflow handling, too - call PyNumber_AsSsize_t, and if an overflow error gets triggered, call PyNumber_Index to find out whether it was positive or negative overflow. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-08-11 20:44 Message: Logged In: YES user_id=5296 I'm attaching a patch that fixes the problem using a more traditional C-API. Their are still 3 new C-API calls --- 1 is actually a macro * PyIndex_Check(obj) * PyNumber_Index(obj) --- is to nb_index as PyNumber_Int is to nb_int * PyNumber_AsSsize_t(obj, err) --- the second argument allows specifying the error when conversion to Pyssize_t raises an Overflow. If err == NULL, the value is clipped instead of raising any error. OverflowError and IndexError are the two errors used in Python itself and the standard library. * I kept the same unit-tests from Nick except that subclasses for integers are allowed as slice indices as this does not cause recursion. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 00:10 Message: Logged In: YES user_id=1038590 Version 5 fast tracks builtin longs as well as ints ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 10:21 Message: Logged In: YES user_id=1038590 Put the priority back to 9 (I accidentally changed it back to 7 when I attached the new patch) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-06 01:10 Message: Logged In: YES user_id=1038590 Added version 4 of the patch. Changes: - is_index is now type_err, with the logical sense inverted and corresponding changes made to other parts of the patch (I didn't use type_error because that would have caused a name clash inside abstract.c) - for consistency in terminology, the internal function used for long conversion is now _PyLong_AsClippedSsize_t to match the PyNumber function, and the output variable used to report clipping is named clipped - an error message from _PyEval_SliceIndex had changed gratuitously, so I restored the original message. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-02 01:28 Message: Logged In: YES user_id=1038590 The minimal fix is still attached (the index_overflow one). That's the patch Tim didn't like. The latter half of the description covers the pep357-fix patch versions. The API's in the more comprehensive patches (_Index, _AsSsize_t, _AsClippedSsize_t) were based on minimising the boilerplate associated with actually *using* those functions to implement the existing operations in the standard library. Without the is_index flag, the mp_subscript implementations all need to perform their own check for whether or not the object provides __index__ or not, since they don't want to raise a TypeError unless the object is *also* not a slice. . However, I'm open to inverting the sense of is_index and changing the name of the output variable to typeerror (an early version of the code actually had it that way around). The only impact on the patch is a bunch of name changes to different variables. In terms of error messages, the patch definitely changes some of the exact wording of raised exceptions. It doesn't change the types, though. The specific change to PyObject_GetItem and friends is that the error message becomes "TypeError: 'foo' object is unsubscriptable" instead of the old "TypeError: 'foo' object is unindexable". The old error message can be restored if you prefer by moving the type check back after the check for whether or not the key is a valid index. However, it really didn't make a lot of sense to me to check the key before we'd even confirmed that the object actually supported subscripting. For the unit tests, I eliminated the use of assert statements in v3 of the patch (as well as updating the tests to cover a bunch of problems with the v2 patch that Travis noted, and to avoid running the same tests multiple times). int_index and long_index went away because the signature change to the nb_index slot (returning PyObject *) meant that the existing int_int and long_long functions were sufficient - there was no need to write new functions specifically for the nb_index slot. This actually applies to any extension type that implements nb_index - it should be populated with the same value as either their nb_int slot or their nb_long slot (depending on whether or not the value will always fit in a Python int) In terms of style (and what may be bothering you), I'm not aware of any existing public CPython API that supports the use of an output flag to indicate errors instead of requiring that callers check PyErr_Occurred. The straightforward approach of providing a PyNumber_IndexCheck API is certainly feasible (and has an identical line count in the mp_subscript functions), but comes at the cost of doing the check twice in every mp_subscript function (once directly and once inside PyNumber_Index). The old code didn't have this problem with doing the same check in two different places because it was merrily calling the nb_index slot directly all over the place instead of going through the abstract API. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 04:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-30 02:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Fri Aug 11 13:47:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 04:47:48 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 20:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 21:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Fri Aug 11 15:27:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 06:27:13 -0700 Subject: [Patches] [ python-Patches-1538691 ] Patch cElementTree to export CurrentLineNumber Message-ID: Patches item #1538691, was opened at 2006-08-11 14:27 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=1538691&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Bryce (robinbryce2) Assigned to: Nobody/Anonymous (nobody) Summary: Patch cElementTree to export CurrentLineNumber Initial Comment: This patch provides to the 'current' position expat api via cElementTree.XMLTreeBuilder. pyexpat already exposes this via the attributes CurrentLineNumber, CurrentColumnNumber and CurrentByteIndex. In order for cElementTree to do the same, the following expat functions are added to those exported via the pyexpat capi: * XML_CurrentLineNumber * XML_CurrentColumnNumber * XML_CurrentByteIndex Then, in _elementtree.c, the xmlparser_getattr is made to mirror the provisions made in pyexpat. A trivial test is added to test_etree_c.py to cover the three new attributes. This patch was motivated by a discussion[1] on the turbogears list that referenced two xml templating libraries Kid & Markup. One of the benefits of the latter is the ability to report line numbers for template source errors. If this patch is applied it should be possible for Kid, and anything else that uses cElementTree for xmlparsing, to do the same. [1] http://groups.google.com/group/turbogears/browse_frm/thread/1ed59ed984fc8bbe/1f06eb00e83f93d9#1f06eb00e83f93d9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538691&group_id=5470 From noreply at sourceforge.net Fri Aug 11 19:15:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 10:15:17 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 10:51 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-11 17:15 Message: Logged In: YES user_id=4771 I like this API too, and the patch looks good apart from some more details: A style note first: some lines are indented with spaces instead of tabs. This causes some changes on otherwise-unchanged lines, too. if PyIndex_Check(key) => if (PyIndex_Check(key)) typeobject.c: slot_nb_index() may not need to do the type-checking because it is done anyway in the caller, which can only be PyNumber_Index(). classobject.c: same remark about instance_index(). unicodeobject.c: kill macro HAS_INDEX mmapmodule.c: idem arraymodule.c: idem should operator.index(o) return PyNumber_AsSsize_t(o) or just PyNumber_Index(o)? I can think of use cases for the latter, which is somehow the most primitive of the two, so it should IMHO be exposed via the operator module. docs: "possitive" => "positive" ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 11:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Fri Aug 11 20:20:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 11:20:53 -0700 Subject: [Patches] [ python-Patches-1538878 ] tkSimpleDialog.askstring() Tcl/Tk-8.4 lockup Message-ID: Patches item #1538878, was opened at 2006-08-11 14: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=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: Open Resolution: None Priority: 5 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538878&group_id=5470 From noreply at sourceforge.net Fri Aug 11 21:16:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 12:16:43 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 04:51 Message generated for change (Comment added) made by teoliphant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Travis Oliphant (teoliphant) Date: 2006-08-11 13:16 Message: Logged In: YES user_id=5296 I've made the changes Armin suggested. I changed operator.index to go back to its original behavior of returning a.__index__() I'm +0 on adding _PyLong_AsClippedSsize_t to clean-up the check for a negative long integer. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-11 11:15 Message: Logged In: YES user_id=4771 I like this API too, and the patch looks good apart from some more details: A style note first: some lines are indented with spaces instead of tabs. This causes some changes on otherwise-unchanged lines, too. if PyIndex_Check(key) => if (PyIndex_Check(key)) typeobject.c: slot_nb_index() may not need to do the type-checking because it is done anyway in the caller, which can only be PyNumber_Index(). classobject.c: same remark about instance_index(). unicodeobject.c: kill macro HAS_INDEX mmapmodule.c: idem arraymodule.c: idem should operator.index(o) return PyNumber_AsSsize_t(o) or just PyNumber_Index(o)? I can think of use cases for the latter, which is somehow the most primitive of the two, so it should IMHO be exposed via the operator module. docs: "possitive" => "positive" ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 05:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Fri Aug 11 23:09:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 14:09:53 -0700 Subject: [Patches] [ python-Patches-1538956 ] Replace unicode.__eq__ exceptions with a warning Message-ID: Patches item #1538956, was opened at 2006-08-11 23:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 Please note that this 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: 9 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Guido van Rossum (gvanrossum) Summary: Replace unicode.__eq__ exceptions with a warning Initial Comment: The attached patch is a first version of the change discussed on python-dev this and last week: It replaces UnicodeDecodeErrors raised during == and != compares of Unicode and other objects with a new UnicodeWarning. All other comparisons continue to raise exceptions. Exceptions other than UnicodeDecodeErrors are also left untouched. The documentation part of the patch is still incomplete. Suggestions are welcome. Due to the change to only the == and != comparison operators, Unicode objects had to grow an implementation for rich comparisons (which now replaces the old tp_compare slot). Tests all pass. Aside: During testing I found that the warning registry defaults to only issueing warnings once per module and line number. I suppose this is enough for debugging code, but it feels weird when trying things in the interactive session, as you only get the warnings once in that context (and for the whole session), regardless of the fact that you're entereing new lines of code all the time. Maybe something to change for Python 2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 From noreply at sourceforge.net Sat Aug 12 01:56:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 16:56:18 -0700 Subject: [Patches] [ python-Patches-1538691 ] Patch cElementTree to export CurrentLineNumber Message-ID: Patches item #1538691, was opened at 2006-08-11 06:27 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538691&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Bryce (robinbryce2) >Assigned to: Fredrik Lundh (effbot) Summary: Patch cElementTree to export CurrentLineNumber Initial Comment: This patch provides to the 'current' position expat api via cElementTree.XMLTreeBuilder. pyexpat already exposes this via the attributes CurrentLineNumber, CurrentColumnNumber and CurrentByteIndex. In order for cElementTree to do the same, the following expat functions are added to those exported via the pyexpat capi: * XML_CurrentLineNumber * XML_CurrentColumnNumber * XML_CurrentByteIndex Then, in _elementtree.c, the xmlparser_getattr is made to mirror the provisions made in pyexpat. A trivial test is added to test_etree_c.py to cover the three new attributes. This patch was motivated by a discussion[1] on the turbogears list that referenced two xml templating libraries Kid & Markup. One of the benefits of the latter is the ability to report line numbers for template source errors. If this patch is applied it should be possible for Kid, and anything else that uses cElementTree for xmlparsing, to do the same. [1] http://groups.google.com/group/turbogears/browse_frm/thread/1ed59ed984fc8bbe/1f06eb00e83f93d9#1f06eb00e83f93d9 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 16:56 Message: Logged In: YES user_id=33168 Fredrik, do you want etree patches here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538691&group_id=5470 From noreply at sourceforge.net Sat Aug 12 07:54:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 22:54:36 -0700 Subject: [Patches] [ python-Patches-1532975 ] Replace the ctypes internal '_as_parameter_' mechanism Message-ID: Patches item #1532975, was opened at 2006-08-02 00:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: Replace the ctypes internal '_as_parameter_' mechanism Initial Comment: This patch removes the '_as_parameter_' public attribute of ctypes instances, and replaces the mechanism by an internal one. This mechanism is used to convert a ctypes instance to an (internal) PyCArgObject instance which can directly by used as an argument in a C function call. With this patch, a C function pointer which does create the PyCArgObject instance is stored in the type dictionary (an StgDict instance). This does speed up foreign function calls with one ctypes argument by about 20%, but more important, it will allow to fix the '_as_parameter_' mechanism, which is documented in [1], so that it actually will work as describes, even for functions that have 'argtypes' set. [1] http://docs.python.org/dev/lib/ctypes-calling-functions-with-own-custom-data-types.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 22:54 Message: Logged In: YES user_id=33168 Please check this in ASAP and remember to make an entry in Misc/NEWS. Also, PyObject_stgdict() can return NULL, but the values aren't checked. There may be a few other unchecked returns. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 01:51 Message: Logged In: YES user_id=11105 The previous patch was against the ctypes repository. I've deleted this patch and attached a new one against the Python svn trunk. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2006-08-02 15:15 Message: Logged In: YES user_id=283742 This patch enables bug fix for the _as_parameter_ mechanism. Please see http://python.org/sf/1533481. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 From noreply at sourceforge.net Sat Aug 12 12:40:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 03:40:23 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 10:51 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-12 10:40 Message: Logged In: YES user_id=4771 The check for a negative long needs to be done differently; this is really depending too much on internal details. Note also that the _long_as_ssize_t() function was introduced to support both long_index() and _PyLong_AsSsize_t(). Now that the former is removed, the situation looks slightly strange, because _long_as_ssize_t() is doing a bit too much work for its one remaining caller. That's why somehow reusing _long_as_ssize_t() from abstract.c would look cleaner to me. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-08-11 19:16 Message: Logged In: YES user_id=5296 I've made the changes Armin suggested. I changed operator.index to go back to its original behavior of returning a.__index__() I'm +0 on adding _PyLong_AsClippedSsize_t to clean-up the check for a negative long integer. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-11 17:15 Message: Logged In: YES user_id=4771 I like this API too, and the patch looks good apart from some more details: A style note first: some lines are indented with spaces instead of tabs. This causes some changes on otherwise-unchanged lines, too. if PyIndex_Check(key) => if (PyIndex_Check(key)) typeobject.c: slot_nb_index() may not need to do the type-checking because it is done anyway in the caller, which can only be PyNumber_Index(). classobject.c: same remark about instance_index(). unicodeobject.c: kill macro HAS_INDEX mmapmodule.c: idem arraymodule.c: idem should operator.index(o) return PyNumber_AsSsize_t(o) or just PyNumber_Index(o)? I can think of use cases for the latter, which is somehow the most primitive of the two, so it should IMHO be exposed via the operator module. docs: "possitive" => "positive" ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 11:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Sat Aug 12 12:50:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 03:50:11 -0700 Subject: [Patches] [ python-Patches-1538956 ] Replace unicode.__eq__ exceptions with a warning Message-ID: Patches item #1538956, was opened at 2006-08-11 21:09 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 Please note that this 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: 9 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Guido van Rossum (gvanrossum) Summary: Replace unicode.__eq__ exceptions with a warning Initial Comment: The attached patch is a first version of the change discussed on python-dev this and last week: It replaces UnicodeDecodeErrors raised during == and != compares of Unicode and other objects with a new UnicodeWarning. All other comparisons continue to raise exceptions. Exceptions other than UnicodeDecodeErrors are also left untouched. The documentation part of the patch is still incomplete. Suggestions are welcome. Due to the change to only the == and != comparison operators, Unicode objects had to grow an implementation for rich comparisons (which now replaces the old tp_compare slot). Tests all pass. Aside: During testing I found that the warning registry defaults to only issueing warnings once per module and line number. I suppose this is enough for debugging code, but it feels weird when trying things in the interactive session, as you only get the warnings once in that context (and for the whole session), regardless of the fact that you're entereing new lines of code all the time. Maybe something to change for Python 2.6. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-12 10:50 Message: Logged In: YES user_id=4771 Getting rid of the special case for unicodes in default_3way_compare() - this alone would give the whole patch a +1 from me :-) Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 From noreply at sourceforge.net Sat Aug 12 16:09:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 07:09:53 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 20:51 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-13 00:09 Message: Logged In: YES user_id=1038590 It's probably worth grabbing just the part of my patch that added the _PyLong_AsClippedSsize_t internal interface to longobject.h - this used an output variable to indicate whether or not clipping occurred, making it easy for abstract.c to decide how to proceed. No doubt some modifications would be needed to fit in with Travis's patch, though, and I won't have time to do that this week. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 20:40 Message: Logged In: YES user_id=4771 The check for a negative long needs to be done differently; this is really depending too much on internal details. Note also that the _long_as_ssize_t() function was introduced to support both long_index() and _PyLong_AsSsize_t(). Now that the former is removed, the situation looks slightly strange, because _long_as_ssize_t() is doing a bit too much work for its one remaining caller. That's why somehow reusing _long_as_ssize_t() from abstract.c would look cleaner to me. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-08-12 05:16 Message: Logged In: YES user_id=5296 I've made the changes Armin suggested. I changed operator.index to go back to its original behavior of returning a.__index__() I'm +0 on adding _PyLong_AsClippedSsize_t to clean-up the check for a negative long integer. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 03:15 Message: Logged In: YES user_id=4771 I like this API too, and the patch looks good apart from some more details: A style note first: some lines are indented with spaces instead of tabs. This causes some changes on otherwise-unchanged lines, too. if PyIndex_Check(key) => if (PyIndex_Check(key)) typeobject.c: slot_nb_index() may not need to do the type-checking because it is done anyway in the caller, which can only be PyNumber_Index(). classobject.c: same remark about instance_index(). unicodeobject.c: kill macro HAS_INDEX mmapmodule.c: idem arraymodule.c: idem should operator.index(o) return PyNumber_AsSsize_t(o) or just PyNumber_Index(o)? I can think of use cases for the latter, which is somehow the most primitive of the two, so it should IMHO be exposed via the operator module. docs: "possitive" => "positive" ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 21:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Sat Aug 12 18:53:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 09:53:51 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 03:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this 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: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 09:53 Message: Logged In: YES user_id=33168 I've modified this patch (mostly for style) and will be checking in today. Armin, I changed the calc for the sign bit to use _PyLong_Sign(). I don't think this patch is perfect (I added some XXX comments), but it needs to get in sooner rather than later. Please try to review what I check in. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-12 07:09 Message: Logged In: YES user_id=1038590 It's probably worth grabbing just the part of my patch that added the _PyLong_AsClippedSsize_t internal interface to longobject.h - this used an output variable to indicate whether or not clipping occurred, making it easy for abstract.c to decide how to proceed. No doubt some modifications would be needed to fit in with Travis's patch, though, and I won't have time to do that this week. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 03:40 Message: Logged In: YES user_id=4771 The check for a negative long needs to be done differently; this is really depending too much on internal details. Note also that the _long_as_ssize_t() function was introduced to support both long_index() and _PyLong_AsSsize_t(). Now that the former is removed, the situation looks slightly strange, because _long_as_ssize_t() is doing a bit too much work for its one remaining caller. That's why somehow reusing _long_as_ssize_t() from abstract.c would look cleaner to me. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-08-11 12:16 Message: Logged In: YES user_id=5296 I've made the changes Armin suggested. I changed operator.index to go back to its original behavior of returning a.__index__() I'm +0 on adding _PyLong_AsClippedSsize_t to clean-up the check for a negative long integer. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-11 10:15 Message: Logged In: YES user_id=4771 I like this API too, and the patch looks good apart from some more details: A style note first: some lines are indented with spaces instead of tabs. This causes some changes on otherwise-unchanged lines, too. if PyIndex_Check(key) => if (PyIndex_Check(key)) typeobject.c: slot_nb_index() may not need to do the type-checking because it is done anyway in the caller, which can only be PyNumber_Index(). classobject.c: same remark about instance_index(). unicodeobject.c: kill macro HAS_INDEX mmapmodule.c: idem arraymodule.c: idem should operator.index(o) return PyNumber_AsSsize_t(o) or just PyNumber_Index(o)? I can think of use cases for the latter, which is somehow the most primitive of the two, so it should IMHO be exposed via the operator module. docs: "possitive" => "positive" ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 04:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Sat Aug 12 19:04:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 10:04:28 -0700 Subject: [Patches] [ python-Patches-1538606 ] Patch to fix __index__() clipping Message-ID: Patches item #1538606, was opened at 2006-08-11 03:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 9 Submitted By: Travis Oliphant (teoliphant) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch to fix __index__() clipping Initial Comment: This is a patch that builds off of Nick Coghlan's work to fix the __index__() clipping problem. It defines 3 New C-API calls (1 is a macro): int PyIndex_Check(obj) -- does this object have nb_index PyObject* PyNumber_Index(obj) -- return nb_index(obj) if possible Py_ssize_t PyNumber_AsSsize_t(obj, err) -- return obj as Py_ssize_t by frist going through nb_index(obj) which returns an integer or long integer. If err is NULL, then clip on Overflow, otherwise raise err on Overflow encountered when trying to fit the result of nb_index into a Py_ssize_t slot. With these three C-API calls, I was able to fix all the problems that have been identified and simplify several pieces of code. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 10:04 Message: Logged In: YES user_id=33168 Committed revision 51236. Please make comments on the checkin. It would probably be best to keep the discussion on python-dev. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 09:53 Message: Logged In: YES user_id=33168 I've modified this patch (mostly for style) and will be checking in today. Armin, I changed the calc for the sign bit to use _PyLong_Sign(). I don't think this patch is perfect (I added some XXX comments), but it needs to get in sooner rather than later. Please try to review what I check in. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-12 07:09 Message: Logged In: YES user_id=1038590 It's probably worth grabbing just the part of my patch that added the _PyLong_AsClippedSsize_t internal interface to longobject.h - this used an output variable to indicate whether or not clipping occurred, making it easy for abstract.c to decide how to proceed. No doubt some modifications would be needed to fit in with Travis's patch, though, and I won't have time to do that this week. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 03:40 Message: Logged In: YES user_id=4771 The check for a negative long needs to be done differently; this is really depending too much on internal details. Note also that the _long_as_ssize_t() function was introduced to support both long_index() and _PyLong_AsSsize_t(). Now that the former is removed, the situation looks slightly strange, because _long_as_ssize_t() is doing a bit too much work for its one remaining caller. That's why somehow reusing _long_as_ssize_t() from abstract.c would look cleaner to me. ---------------------------------------------------------------------- Comment By: Travis Oliphant (teoliphant) Date: 2006-08-11 12:16 Message: Logged In: YES user_id=5296 I've made the changes Armin suggested. I changed operator.index to go back to its original behavior of returning a.__index__() I'm +0 on adding _PyLong_AsClippedSsize_t to clean-up the check for a negative long integer. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-11 10:15 Message: Logged In: YES user_id=4771 I like this API too, and the patch looks good apart from some more details: A style note first: some lines are indented with spaces instead of tabs. This causes some changes on otherwise-unchanged lines, too. if PyIndex_Check(key) => if (PyIndex_Check(key)) typeobject.c: slot_nb_index() may not need to do the type-checking because it is done anyway in the caller, which can only be PyNumber_Index(). classobject.c: same remark about instance_index(). unicodeobject.c: kill macro HAS_INDEX mmapmodule.c: idem arraymodule.c: idem should operator.index(o) return PyNumber_AsSsize_t(o) or just PyNumber_Index(o)? I can think of use cases for the latter, which is somehow the most primitive of the two, so it should IMHO be exposed via the operator module. docs: "possitive" => "positive" ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-11 04:47 Message: Logged In: YES user_id=1038590 The PyNumber_Index docs should explicitly state that it raises IndexError when overflow occurs. It may also be worth resurrecting _PyLong_AsClippedSsize_t in order to clean up the implementation of PyNumber_AsSsize_t (detecting OverflowError then poking around in the guts of a long object is a bit ugly). Other than that, looks good to me (I like this API a lot better than mine). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538606&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:02:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:02:28 -0700 Subject: [Patches] [ python-Patches-1538956 ] Replace unicode.__eq__ exceptions with a warning Message-ID: Patches item #1538956, was opened at 2006-08-11 14:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 9 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: M.-A. Lemburg (lemburg) Summary: Replace unicode.__eq__ exceptions with a warning Initial Comment: The attached patch is a first version of the change discussed on python-dev this and last week: It replaces UnicodeDecodeErrors raised during == and != compares of Unicode and other objects with a new UnicodeWarning. All other comparisons continue to raise exceptions. Exceptions other than UnicodeDecodeErrors are also left untouched. The documentation part of the patch is still incomplete. Suggestions are welcome. Due to the change to only the == and != comparison operators, Unicode objects had to grow an implementation for rich comparisons (which now replaces the old tp_compare slot). Tests all pass. Aside: During testing I found that the warning registry defaults to only issueing warnings once per module and line number. I suppose this is enough for debugging code, but it feels weird when trying things in the interactive session, as you only get the warnings once in that context (and for the whole session), regardless of the fact that you're entereing new lines of code all the time. Maybe something to change for Python 2.6. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:02 Message: Logged In: YES user_id=33168 I don't know the intricasies of rich comparisons, but this looks pretty good. There are some typos: silcence (drop the first c, comment in unicodeobject.c). I think the doc (Doc/lib/libexcs.tex) is missing an \end{excdesc}. In Misc/NEWS, "can be then filtered" is awkward, drop the 'then'. Misc/NEWS should mention the new public API PyUnicode_RichCompare (and point out that UnicodeWarning is new). Please check this in ASAP and report to python-dev. That way if there are any issues, we can try to resolve them quickly. People are more likely to review the checkin the patch on SF. Improving warnings in 2.6 would definitely be nice. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 03:50 Message: Logged In: YES user_id=4771 Getting rid of the special case for unicodes in default_3way_compare() - this alone would give the whole patch a +1 from me :-) Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 From noreply at sourceforge.net Sun Aug 13 05:16:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 20:16:11 -0700 Subject: [Patches] [ python-Patches-1539381 ] Add readinto method to StringIO and cStringIO Message-ID: Patches item #1539381, was opened at 2006-08-12 23:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1539381&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Add readinto method to StringIO and cStringIO Initial Comment: Added a 'readonly' flag to buffer object constructor (needed to implement StringIO.readinto). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1539381&group_id=5470 From noreply at sourceforge.net Mon Aug 14 12:57:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 03:57:08 -0700 Subject: [Patches] [ python-Patches-1538956 ] Replace unicode.__eq__ exceptions with a warning Message-ID: Patches item #1538956, was opened at 2006-08-11 23:09 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 9 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: Replace unicode.__eq__ exceptions with a warning Initial Comment: The attached patch is a first version of the change discussed on python-dev this and last week: It replaces UnicodeDecodeErrors raised during == and != compares of Unicode and other objects with a new UnicodeWarning. All other comparisons continue to raise exceptions. Exceptions other than UnicodeDecodeErrors are also left untouched. The documentation part of the patch is still incomplete. Suggestions are welcome. Due to the change to only the == and != comparison operators, Unicode objects had to grow an implementation for rich comparisons (which now replaces the old tp_compare slot). Tests all pass. Aside: During testing I found that the warning registry defaults to only issueing warnings once per module and line number. I suppose this is enough for debugging code, but it feels weird when trying things in the interactive session, as you only get the warnings once in that context (and for the whole session), regardless of the fact that you're entereing new lines of code all the time. Maybe something to change for Python 2.6. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-14 12:57 Message: Logged In: YES user_id=38388 Thanks for the typo-checks, Neal. Checked in a slightly updated version as revision 51276. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:02 Message: Logged In: YES user_id=33168 I don't know the intricasies of rich comparisons, but this looks pretty good. There are some typos: silcence (drop the first c, comment in unicodeobject.c). I think the doc (Doc/lib/libexcs.tex) is missing an \end{excdesc}. In Misc/NEWS, "can be then filtered" is awkward, drop the 'then'. Misc/NEWS should mention the new public API PyUnicode_RichCompare (and point out that UnicodeWarning is new). Please check this in ASAP and report to python-dev. That way if there are any issues, we can try to resolve them quickly. People are more likely to review the checkin the patch on SF. Improving warnings in 2.6 would definitely be nice. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 12:50 Message: Logged In: YES user_id=4771 Getting rid of the special case for unicodes in default_3way_compare() - this alone would give the whole patch a +1 from me :-) Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1538956&group_id=5470 From noreply at sourceforge.net Mon Aug 14 16:14:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 07:14:34 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 12:07 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this 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: 6 Submitted By: Tal Einat (taleinat) Assigned to: Kurt B. Kaiser (kbk) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-14 10:14 Message: Logged In: YES user_id=149084 2.5b3 Rev 51189. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-10 13:14 Message: Logged In: YES user_id=149084 2.5b3 Rev 51189. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-30 08:06 Message: Logged In: YES user_id=1330769 I uploaded an update (another patch, apply after applying the first one), this fixes the behavior a bit. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-27 16:48 Message: Logged In: YES user_id=1330769 Bah, sorry for forgetting to post the file... It really was getting late that night :P ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 16:30 Message: Logged In: YES user_id=149084 Well, once you get it throughly tested, please attach the patch so I can look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Mon Aug 14 16:20:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 07:20:53 -0700 Subject: [Patches] [ python-Patches-1532975 ] Replace the ctypes internal '_as_parameter_' mechanism Message-ID: Patches item #1532975, was opened at 2006-08-02 09:57 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Replace the ctypes internal '_as_parameter_' mechanism Initial Comment: This patch removes the '_as_parameter_' public attribute of ctypes instances, and replaces the mechanism by an internal one. This mechanism is used to convert a ctypes instance to an (internal) PyCArgObject instance which can directly by used as an argument in a C function call. With this patch, a C function pointer which does create the PyCArgObject instance is stored in the type dictionary (an StgDict instance). This does speed up foreign function calls with one ctypes argument by about 20%, but more important, it will allow to fix the '_as_parameter_' mechanism, which is documented in [1], so that it actually will work as describes, even for functions that have 'argtypes' set. [1] http://docs.python.org/dev/lib/ctypes-calling-functions-with-own-custom-data-types.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-14 16:20 Message: Logged In: YES user_id=11105 A variant of this patch together with the general idea of the patch in #1533481 was committed as SVN rev. 51227. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 07:54 Message: Logged In: YES user_id=33168 Please check this in ASAP and remember to make an entry in Misc/NEWS. Also, PyObject_stgdict() can return NULL, but the values aren't checked. There may be a few other unchecked returns. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 10:51 Message: Logged In: YES user_id=11105 The previous patch was against the ctypes repository. I've deleted this patch and attached a new one against the Python svn trunk. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2006-08-03 00:15 Message: Logged In: YES user_id=283742 This patch enables bug fix for the _as_parameter_ mechanism. Please see http://python.org/sf/1533481. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1532975&group_id=5470 From noreply at sourceforge.net Mon Aug 14 18:21:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 09:21:54 -0700 Subject: [Patches] [ python-Patches-1536908 ] Build ctypes on OpenBSD x86_64 Message-ID: Patches item #1536908, was opened at 2006-08-08 20:39 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Build ctypes on OpenBSD x86_64 Initial Comment: This patch from Damien Miller enables building ctypes on OpenBSD x86_64. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-14 18:21 Message: Logged In: YES user_id=11105 Committed as rev 51281. I removed the '-no-stack-protector' flag because two people have confirmed that at least the testsuite doesn't need it. ---------------------------------------------------------------------- Comment By: djmdjm (djmdjm) Date: 2006-08-10 08:31 Message: Logged In: YES user_id=1359232 I have tested the -fno-stack-protector on OpenBSD i386 and AMD64 - it passes regress tests on both. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-08 23:40 Message: Logged In: YES user_id=33168 Thomas, you can apply this if you want. Are you sure about the last bit about remove -fno-stack-protector though? That part seems a bit more dangerous, but I'll leave the decision up to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536908&group_id=5470 From noreply at sourceforge.net Mon Aug 14 23:46:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 14:46:13 -0700 Subject: [Patches] [ python-Patches-1535500 ] writelines() in bz2 module does not raise check for errors Message-ID: Patches item #1535500, was opened at 2006-08-06 19:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535500&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lawrence Oluyede (rhymes) Assigned to: Nobody/Anonymous (nobody) Summary: writelines() in bz2 module does not raise check for errors Initial Comment: In the BZ2File object of bz2 module the writelines() method does not check its closed state before doing the actual work so its behavior it's different from write()'s behavior. See: >>> from bz2 import BZ2File >>> f = BZ2File("foo", "w") >>> f.close() >>> f.closed 1 >>> f.write("foobar") Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file >>> f.closed 1 >>> f.writelines(["foobar"]) Traceback (most recent call last): File "", line 1, in IOError: unknown IO error It also doesn't check if it can write for real: >>> from bz2 import BZ2File >>> f = BZ2File("foo", "r") >>> f.write("foobar") Traceback (most recent call last): File "", line 1, in IOError: file is not ready for writing >>> f.writelines(['foobar']) Traceback (most recent call last): File "", line 1, in RuntimeError: wrong sequence of bz2 library commands used ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:46 Message: Logged In: YES user_id=849994 Thanks for the patch, this has been fixed in rev. 51285--51288. (The first example actually segfaulted here!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535500&group_id=5470 From noreply at sourceforge.net Mon Aug 14 23:55:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 14:55:44 -0700 Subject: [Patches] [ python-Patches-1536071 ] trace.py on win32 has problems with lowercase drive names Message-ID: Patches item #1536071, was opened at 2006-08-07 15:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536071&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Adam Groszer (agroszer) Assigned to: Nobody/Anonymous (nobody) Summary: trace.py on win32 has problems with lowercase drive names Initial Comment: The following patch should solve it: --- svn-trace.py-46805 +++ U:\Python24\Lib\trace.py @@ -179,8 +177,12 @@ # looking in sys.path for the longest matching prefix. We'll # assume that the rest is the package name. + path = os.path.normcase(path) + longest = "" for dir in sys.path: + dir = os.path.normcase(dir) + if path.startswith(dir) and path[len(dir)] == os.path.sep: if len(dir) > len(longest): longest = dir ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:55 Message: Logged In: YES user_id=849994 Thanks for the patch, applied in rev. 51289. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1536071&group_id=5470 From noreply at sourceforge.net Mon Aug 14 23:57:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 14:57:09 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Mon Aug 14 23:58:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 14:58:21 -0700 Subject: [Patches] [ python-Patches-1526367 ] str.__iter__ and unicode.__iter__ Message-ID: Patches item #1526367, was opened at 2006-07-21 09:39 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: str.__iter__ and unicode.__iter__ Initial Comment: This patch add iterator classes for str and unicode, as discussed here: http://mail.python.org/pipermail/python-3000/2006-July/002650.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 From noreply at sourceforge.net Tue Aug 15 00:01:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 15:01:38 -0700 Subject: [Patches] [ python-Patches-1521882 ] Give Cookie.py its own _idmap Message-ID: Patches item #1521882, was opened at 2006-07-13 15:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521882&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Give Cookie.py its own _idmap Initial Comment: Currently, Lib/Cookie.py relies on being able to import _idmap -- an internal implementation detail -- from string.py. Given that string.py includes a comment "Note that Cookie.py bogusly uses _idmap :(", it seems this might be something worth fixing. The attached patch resolves this issue by having Cookie.py generate its own copy of _idmap. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 22:01 Message: Logged In: YES user_id=849994 Applied as rev. 51290. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-03 00:16 Message: Logged In: YES user_id=1126061 For what my opinion's worth, this patch looks fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521882&group_id=5470 From noreply at sourceforge.net Tue Aug 15 00:04:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 15:04:55 -0700 Subject: [Patches] [ python-Patches-1513299 ] Clean up usage of map() in the stdlib Message-ID: Patches item #1513299, was opened at 2006-06-27 12:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Clean up usage of map() in the stdlib Initial Comment: This patch cleans up the usage of map() in the standard library. Among other things, it removes several usages of things like map(None, x), as well as simplifying a number of map(lambda: ..., x) expressions. This patch is against r47124. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 22:04 Message: Logged In: YES user_id=849994 Can wait until 2.6. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-25 08:24 Message: Logged In: YES user_id=29957 map(None, ...) should definitely be expunged. The others should be addressed on a case-by-case basis. I'll have a read-through of the patch. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 16:53 Message: Logged In: YES user_id=1344176 Updated the patch to r47131 and added a bunch of new cleanups. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 15:46 Message: Logged In: YES user_id=764593 There are none I would suggest reverting; it is just that some are clear wins and others are not so important. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 15:24 Message: Logged In: YES user_id=1344176 Which ones would you like to see reverted (ie, which ones are not an improvement)? I've found some more cases that can be improved, so a new version of the patch will be on the way shortly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 15:15 Message: Logged In: YES user_id=764593 Some cases are definately an improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 From noreply at sourceforge.net Tue Aug 15 00:08:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 15:08:19 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23:35 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-14 22:08 Message: Logged In: YES user_id=1126061 Tim Peters expressed that he liked the idea of rewriting the test using the unittest module. However, I can appreciate introducing changes in small steps, so if you reply with a "yes change the tset" I'll have no problem writing another non-unittest patch. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Tue Aug 15 00:10:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 15:10:37 -0700 Subject: [Patches] [ python-Patches-1511317 ] socket.gethostbyaddr fix for machines with incomplete DNS Message-ID: Patches item #1511317, was opened at 2006-06-23 13:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1511317&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Charles Schwieters (chuckorama) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyaddr fix for machines with incomplete DNS Initial Comment: I found that socket.gethostbyaddr would crash 2.4.3 on machines with incomplete DNS, such as scyld cluster nodes. The following one line obvious patch fixes the problem. Charles ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 22:10 Message: Logged In: YES user_id=849994 Applied as rev. 51291. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1511317&group_id=5470 From noreply at sourceforge.net Tue Aug 15 00:12:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 15:12:07 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 22:12 Message: Logged In: YES user_id=849994 If you get someone else to review the full patch, it's fine with me. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-14 22:08 Message: Logged In: YES user_id=1126061 Tim Peters expressed that he liked the idea of rewriting the test using the unittest module. However, I can appreciate introducing changes in small steps, so if you reply with a "yes change the tset" I'll have no problem writing another non-unittest patch. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Tue Aug 15 03:31:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 18:31:10 -0700 Subject: [Patches] [ python-Patches-1540329 ] Backports from trunk to release24-maint Message-ID: Patches item #1540329, was opened at 2006-08-15 01:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: flub (bruynooghef) Assigned to: Nobody/Anonymous (nobody) Summary: Backports from trunk to release24-maint Initial Comment: Backports of _hotshot.c only: r41768, r45341, r51218 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540329&group_id=5470 From noreply at sourceforge.net Tue Aug 15 06:47:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 21:47:16 -0700 Subject: [Patches] [ python-Patches-1540385 ] tarfile __slots__ addition Message-ID: Patches item #1540385, was opened at 2006-08-14 23:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile __slots__ addition Initial Comment: Quicky mod, use __slots__ for TarInfo objects in tarfile module; lot of slots, but reduces memory by around 33% in testing. Pardon the delay in submitting; would like to see it in 2.5, but also well aware it's pushing it time wise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 From noreply at sourceforge.net Tue Aug 15 08:55:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 23:55:36 -0700 Subject: [Patches] [ python-Patches-1540385 ] tarfile __slots__ addition Message-ID: Patches item #1540385, was opened at 2006-08-15 06:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile __slots__ addition Initial Comment: Quicky mod, use __slots__ for TarInfo objects in tarfile module; lot of slots, but reduces memory by around 33% in testing. Pardon the delay in submitting; would like to see it in 2.5, but also well aware it's pushing it time wise. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-15 08:55 Message: Logged In: YES user_id=21627 It definitely can't get into 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 From noreply at sourceforge.net Tue Aug 15 10:37:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 01:37:05 -0700 Subject: [Patches] [ python-Patches-1540470 ] Patches for OpenBSD 4.0 Message-ID: Patches item #1540470, was opened at 2006-08-15 18:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: djmdjm (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for OpenBSD 4.0 Initial Comment: Hi, There are several points in the Python-2.5b3 code that need to be modified to properly support OpenBSD 4.x. This is mostly because of a dependence on sys.platform returning "openbsd3", which is no longer true for OpenBSD CVS - OpenBSD 4.0 is in beta right now, to be released in a couple of months. The attached patch (against SVN head) fixes this. It would be great if this can make it in for Python-2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 From noreply at sourceforge.net Tue Aug 15 13:13:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 04:13:54 -0700 Subject: [Patches] [ python-Patches-1540470 ] Patches for OpenBSD 4.0 Message-ID: Patches item #1540470, was opened at 2006-08-15 08:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for OpenBSD 4.0 Initial Comment: Hi, There are several points in the Python-2.5b3 code that need to be modified to properly support OpenBSD 4.x. This is mostly because of a dependence on sys.platform returning "openbsd3", which is no longer true for OpenBSD CVS - OpenBSD 4.0 is in beta right now, to be released in a couple of months. The attached patch (against SVN head) fixes this. It would be great if this can make it in for Python-2.5. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 11:13 Message: Logged In: YES user_id=849994 Speaking of OpenBSD, Gentoo has an additional patch to compile for OpenBSD, I'll attach it here without looking into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 From noreply at sourceforge.net Tue Aug 15 15:19:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 06:19:35 -0700 Subject: [Patches] [ python-Patches-1540617 ] Use Py_ssize_t for rangeobject members Message-ID: Patches item #1540617, was opened at 2006-08-15 09:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540617&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use Py_ssize_t for rangeobject members Initial Comment: Use Py_ssize_t for rangeobject start, step and len and rangeiterobject's index, start, step and length. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540617&group_id=5470 From noreply at sourceforge.net Tue Aug 15 15:21:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 06:21:50 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-03 09:35 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-08-15 23:21 Message: Logged In: YES user_id=250749 I should have noted in this item when I checked in rev 51133 that it included the essence of this patch (skipping the thread stack size testing on platfforms that don't support the feature) within the existing test framework. Thus 2.5b3 should correctly handle this situation - if it doesn't, please say so. I understood that it was too late in the 2.5 release process to admit a rewrite and so was waiting for the release to branch before bringing the patch into the trunk. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 08:12 Message: Logged In: YES user_id=849994 If you get someone else to review the full patch, it's fine with me. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-15 08:08 Message: Logged In: YES user_id=1126061 Tim Peters expressed that he liked the idea of rewriting the test using the unittest module. However, I can appreciate introducing changes in small steps, so if you reply with a "yes change the tset" I'll have no problem writing another non-unittest patch. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 07:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Tue Aug 15 15:45:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 06:45:35 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23:35 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-15 13:45 Message: Logged In: YES user_id=1126061 The test doesn't pass because the output produced from test_thread.py is diffed against Lib/test/output/test_thread Here's the output from running the test test test_thread produced unexpected output: ********************************************************************** *** mismatch between lines 9-18 of expected output and line 9 of actual output: + platform does not support changing thread stack size - caught expected ValueError setting stack_size(4096) - successfully set stack_size(262144) - successfully set stack_size(1048576) - successfully set stack_size(0) - trying stack_size = 262144 - waiting for all tasks to complete - all tasks done - trying stack_size = 1048576 - waiting for all tasks to complete - all tasks done *********************************************** ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-08-15 13:21 Message: Logged In: YES user_id=250749 I should have noted in this item when I checked in rev 51133 that it included the essence of this patch (skipping the thread stack size testing on platfforms that don't support the feature) within the existing test framework. Thus 2.5b3 should correctly handle this situation - if it doesn't, please say so. I understood that it was too late in the 2.5 release process to admit a rewrite and so was waiting for the release to branch before bringing the patch into the trunk. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 22:12 Message: Logged In: YES user_id=849994 If you get someone else to review the full patch, it's fine with me. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-14 22:08 Message: Logged In: YES user_id=1126061 Tim Peters expressed that he liked the idea of rewriting the test using the unittest module. However, I can appreciate introducing changes in small steps, so if you reply with a "yes change the tset" I'll have no problem writing another non-unittest patch. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Tue Aug 15 16:32:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 07:32:27 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-03 09:35 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-08-16 00:32 Message: Logged In: YES user_id=250749 Sorry, r51133 went in after 2.5b3, but your test would seem to be done with a SVN checkout? As far as I know, the failure you note cannot be resolved without the rewrite to use unittest (or doctest?), which is out of scope until after 2.5 - at least not without removing most of the content of Lib/test/output/test_thread. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-15 23:45 Message: Logged In: YES user_id=1126061 The test doesn't pass because the output produced from test_thread.py is diffed against Lib/test/output/test_thread Here's the output from running the test test test_thread produced unexpected output: ********************************************************************** *** mismatch between lines 9-18 of expected output and line 9 of actual output: + platform does not support changing thread stack size - caught expected ValueError setting stack_size(4096) - successfully set stack_size(262144) - successfully set stack_size(1048576) - successfully set stack_size(0) - trying stack_size = 262144 - waiting for all tasks to complete - all tasks done - trying stack_size = 1048576 - waiting for all tasks to complete - all tasks done *********************************************** ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-08-15 23:21 Message: Logged In: YES user_id=250749 I should have noted in this item when I checked in rev 51133 that it included the essence of this patch (skipping the thread stack size testing on platfforms that don't support the feature) within the existing test framework. Thus 2.5b3 should correctly handle this situation - if it doesn't, please say so. I understood that it was too late in the 2.5 release process to admit a rewrite and so was waiting for the release to branch before bringing the patch into the trunk. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 08:12 Message: Logged In: YES user_id=849994 If you get someone else to review the full patch, it's fine with me. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-15 08:08 Message: Logged In: YES user_id=1126061 Tim Peters expressed that he liked the idea of rewriting the test using the unittest module. However, I can appreciate introducing changes in small steps, so if you reply with a "yes change the tset" I'll have no problem writing another non-unittest patch. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 07:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Tue Aug 15 17:01:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 08:01:17 -0700 Subject: [Patches] [ python-Patches-1533520 ] Allow thread(ing) tests to pass without setting stack size Message-ID: Patches item #1533520, was opened at 2006-08-02 23:35 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Allow thread(ing) tests to pass without setting stack size Initial Comment: This patch changes Lib/test/test_thread.py to use the unit test framework. It also allows platforms that do not support changing the stack size of threads to pass all thread tests. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-15 15:01 Message: Logged In: YES user_id=1126061 Yes the test was done with an update from trunk as of five minutes before I posted the message. It's probably just a better idea for me to shut up, and we'll resolve this after 2.5? ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-08-15 14:32 Message: Logged In: YES user_id=250749 Sorry, r51133 went in after 2.5b3, but your test would seem to be done with a SVN checkout? As far as I know, the failure you note cannot be resolved without the rewrite to use unittest (or doctest?), which is out of scope until after 2.5 - at least not without removing most of the content of Lib/test/output/test_thread. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-15 13:45 Message: Logged In: YES user_id=1126061 The test doesn't pass because the output produced from test_thread.py is diffed against Lib/test/output/test_thread Here's the output from running the test test test_thread produced unexpected output: ********************************************************************** *** mismatch between lines 9-18 of expected output and line 9 of actual output: + platform does not support changing thread stack size - caught expected ValueError setting stack_size(4096) - successfully set stack_size(262144) - successfully set stack_size(1048576) - successfully set stack_size(0) - trying stack_size = 262144 - waiting for all tasks to complete - all tasks done - trying stack_size = 1048576 - waiting for all tasks to complete - all tasks done *********************************************** ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-08-15 13:21 Message: Logged In: YES user_id=250749 I should have noted in this item when I checked in rev 51133 that it included the essence of this patch (skipping the thread stack size testing on platfforms that don't support the feature) within the existing test framework. Thus 2.5b3 should correctly handle this situation - if it doesn't, please say so. I understood that it was too late in the 2.5 release process to admit a rewrite and so was waiting for the release to branch before bringing the patch into the trunk. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 22:12 Message: Logged In: YES user_id=849994 If you get someone else to review the full patch, it's fine with me. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-14 22:08 Message: Logged In: YES user_id=1126061 Tim Peters expressed that he liked the idea of rewriting the test using the unittest module. However, I can appreciate introducing changes in small steps, so if you reply with a "yes change the tset" I'll have no problem writing another non-unittest patch. Matt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:57 Message: Logged In: YES user_id=849994 For the 2.5 release, could you please post a patch without the conversion to unittest? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533520&group_id=5470 From noreply at sourceforge.net Tue Aug 15 20:55:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 11:55:39 -0700 Subject: [Patches] [ python-Patches-1540849 ] except too broad Message-ID: Patches item #1540849, was opened at 2006-08-15 14:55 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=1540849&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: except too broad Initial Comment: IOBinding.open looks for an self.editwin.interp (after having already verified that self.editwin exists), but catches exceptions with a bare except. This narrows it to an AttributeError. (Note that the save method already assumes that missing attributes on an editwin will be represented as AtributeError rather than TypeError.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540849&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:00:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:00:54 -0700 Subject: [Patches] [ python-Patches-1540851 ] with is now a blockopener Message-ID: Patches item #1540851, was opened at 2006-08-15 15: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=1540851&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: with is now a blockopener Initial Comment: idlelib/CodeContext.py keeps a list of statements that can start an indented block. with should be added to this list in 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:05:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:05:05 -0700 Subject: [Patches] [ python-Patches-1540856 ] IOBinding overly broad except (2nd try) Message-ID: Patches item #1540856, was opened at 2006-08-15 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540856&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: IOBinding overly broad except (2nd try) Initial Comment: Given that self.editwin exists, and missing attributes raise AttributeError (as assumed by the save method), this should only catch AttributeError. Note that this isn't in a "don't fail for any reason" section. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540856&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:06:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:06:13 -0700 Subject: [Patches] [ python-Patches-1540857 ] except too broad Message-ID: Patches item #1540857, was opened at 2006-08-15 15:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540857&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: except too broad Initial Comment: IOBinding.open looks for an self.editwin.interp (after having already verified that self.editwin exists), but catches exceptions with a bare except. This narrows it to an AttributeError. (Note that the save method already assumes that missing attributes on an editwin will be represented as AtributeError rather than TypeError.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540857&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:08:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:08:37 -0700 Subject: [Patches] [ python-Patches-1540859 ] IOBinding broad except - try 3 Message-ID: Patches item #1540859, was opened at 2006-08-15 15:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540859&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: IOBinding broad except - try 3 Initial Comment: IOBinding uses a bare except, when it should catch only AttributeError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540859&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:11:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:11:14 -0700 Subject: [Patches] [ python-Patches-1540856 ] IOBinding overly broad except (2nd try) Message-ID: Patches item #1540856, was opened at 2006-08-15 15:05 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540856&group_id=5470 Please note that this 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.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: IOBinding overly broad except (2nd try) Initial Comment: Given that self.editwin exists, and missing attributes raise AttributeError (as assumed by the save method), this should only catch AttributeError. Note that this isn't in a "don't fail for any reason" section. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:11 Message: Logged In: YES user_id=764593 duplicate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540856&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:11:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:11:53 -0700 Subject: [Patches] [ python-Patches-1540856 ] IOBinding overly broad except (2nd try) Message-ID: Patches item #1540856, was opened at 2006-08-15 15:05 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540856&group_id=5470 Please note that this 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.4 Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: IOBinding overly broad except (2nd try) Initial Comment: Given that self.editwin exists, and missing attributes raise AttributeError (as assumed by the save method), this should only catch AttributeError. Note that this isn't in a "don't fail for any reason" section. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:11 Message: Logged In: YES user_id=764593 duplicate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540856&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:12:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:12:36 -0700 Subject: [Patches] [ python-Patches-1540857 ] except too broad Message-ID: Patches item #1540857, was opened at 2006-08-15 15:06 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540857&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: except too broad Initial Comment: IOBinding.open looks for an self.editwin.interp (after having already verified that self.editwin exists), but catches exceptions with a bare except. This narrows it to an AttributeError. (Note that the save method already assumes that missing attributes on an editwin will be represented as AtributeError rather than TypeError.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540857&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:12:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:12:57 -0700 Subject: [Patches] [ python-Patches-1540859 ] IOBinding broad except - try 3 Message-ID: Patches item #1540859, was opened at 2006-08-15 15:08 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540859&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: IOBinding broad except - try 3 Initial Comment: IOBinding uses a bare except, when it should catch only AttributeError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540859&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:20:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:20:29 -0700 Subject: [Patches] [ python-Patches-1540869 ] CodeContext visibility Message-ID: Patches item #1540869, was opened at 2006-08-15 15: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=1540869&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: CodeContext visibility Initial Comment: CodeContext hardcodes several constants; these two in particular make it difficult to visually separate the "context" from the top of the regular code. Ideally, the measurement would change to something like em or ex, but ... this was an improvement. Note that the separation is explicitly there in the code already; it just doesn't work with the current constants. If the Relesae Manager decides to delay it to 2.6 (or backport to 2.4), I won't object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:29:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:29:03 -0700 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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540874&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:51:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:51:08 -0700 Subject: [Patches] [ python-Patches-1540892 ] make IDLE honor the quit() builtin Message-ID: Patches item #1540892, was opened at 2006-08-15 15:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: make IDLE honor the quit() builtin Initial Comment: As of 2.5, quit() should exit. Certain wrapping environments (including IDLE) didn't honor this. This patch fixes at least idle, by having the Quitter() object (try to) close sys.stdin before raising SystemExit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:52:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:52:41 -0700 Subject: [Patches] [ python-Patches-1540892 ] make IDLE honor the quit() builtin Message-ID: Patches item #1540892, was opened at 2006-08-15 15:51 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 Please note that this 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: Open Resolution: None >Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: make IDLE honor the quit() builtin Initial Comment: As of 2.5, quit() should exit. Certain wrapping environments (including IDLE) didn't honor this. This patch fixes at least idle, by having the Quitter() object (try to) close sys.stdin before raising SystemExit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:55:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:55:33 -0700 Subject: [Patches] [ python-Patches-1540851 ] with is now a blockopener Message-ID: Patches item #1540851, was opened at 2006-08-15 15:00 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 Please note that this 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: Open Resolution: None >Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: with is now a blockopener Initial Comment: idlelib/CodeContext.py keeps a list of statements that can start an indented block. with should be added to this list in 2.5 ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:55 Message: Logged In: YES user_id=764593 Changing priority to 7, because 2.5 is the first release with "with", even though it still takes __future__ declaration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 From noreply at sourceforge.net Tue Aug 15 21:57:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 12:57:31 -0700 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 jimjjewett 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: Open Resolution: None >Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) 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: 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 Wed Aug 16 04:56:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 19:56:18 -0700 Subject: [Patches] [ python-Patches-1540849 ] except too broad Message-ID: Patches item #1540849, was opened at 2006-08-15 14:55 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540849&group_id=5470 Please note that this 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.6 Status: Open >Resolution: Later Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Kurt B. Kaiser (kbk) Summary: except too broad Initial Comment: IOBinding.open looks for an self.editwin.interp (after having already verified that self.editwin exists), but catches exceptions with a bare except. This narrows it to an AttributeError. (Note that the save method already assumes that missing attributes on an editwin will be represented as AtributeError rather than TypeError.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540849&group_id=5470 From noreply at sourceforge.net Wed Aug 16 04:56:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 19:56:52 -0700 Subject: [Patches] [ python-Patches-1540851 ] with is now a blockopener Message-ID: Patches item #1540851, was opened at 2006-08-15 15:00 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 Please note that this 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: Open Resolution: None Priority: 7 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Kurt B. Kaiser (kbk) Summary: with is now a blockopener Initial Comment: idlelib/CodeContext.py keeps a list of statements that can start an indented block. with should be added to this list in 2.5 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:55 Message: Logged In: YES user_id=764593 Changing priority to 7, because 2.5 is the first release with "with", even though it still takes __future__ declaration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 From noreply at sourceforge.net Wed Aug 16 04:58:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 19:58:43 -0700 Subject: [Patches] [ python-Patches-1540869 ] CodeContext visibility Message-ID: Patches item #1540869, was opened at 2006-08-15 15:20 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 Please note that this 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.6 Status: Open >Resolution: Later Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext visibility Initial Comment: CodeContext hardcodes several constants; these two in particular make it difficult to visually separate the "context" from the top of the regular code. Ideally, the measurement would change to something like em or ex, but ... this was an improvement. Note that the separation is explicitly there in the code already; it just doesn't work with the current constants. If the Relesae Manager decides to delay it to 2.6 (or backport to 2.4), I won't object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 From noreply at sourceforge.net Wed Aug 16 05:00:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 20:00:06 -0700 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 (Settings changed) 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: Open Resolution: None Priority: 7 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: 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 Wed Aug 16 05:05:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 20:05:16 -0700 Subject: [Patches] [ python-Patches-1540892 ] make IDLE honor the quit() builtin Message-ID: Patches item #1540892, was opened at 2006-08-15 15:51 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 Please note that this 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: Open Resolution: None Priority: 7 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Kurt B. Kaiser (kbk) Summary: make IDLE honor the quit() builtin Initial Comment: As of 2.5, quit() should exit. Certain wrapping environments (including IDLE) didn't honor this. This patch fixes at least idle, by having the Quitter() object (try to) close sys.stdin before raising SystemExit. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-15 23:05 Message: Logged In: YES user_id=149084 Bug 1479785 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 From noreply at sourceforge.net Wed Aug 16 05:16:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 20:16:30 -0700 Subject: [Patches] [ python-Patches-1540851 ] with is now a blockopener Message-ID: Patches item #1540851, was opened at 2006-08-15 15:00 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 Please note that this 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: Accepted Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: with is now a blockopener Initial Comment: idlelib/CodeContext.py keeps a list of statements that can start an indented block. with should be added to this list in 2.5 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-15 23:16 Message: Logged In: YES user_id=149084 Rev 51303. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-15 15:55 Message: Logged In: YES user_id=764593 Changing priority to 7, because 2.5 is the first release with "with", even though it still takes __future__ declaration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540851&group_id=5470 From noreply at sourceforge.net Wed Aug 16 07:02:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 22:02:28 -0700 Subject: [Patches] [ python-Patches-1540892 ] make IDLE honor the quit() builtin Message-ID: Patches item #1540892, was opened at 2006-08-15 15:51 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 Please note that this 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: Accepted Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: make IDLE honor the quit() builtin Initial Comment: As of 2.5, quit() should exit. Certain wrapping environments (including IDLE) didn't honor this. This patch fixes at least idle, by having the Quitter() object (try to) close sys.stdin before raising SystemExit. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 01:02 Message: Logged In: YES user_id=149084 Rev 51306. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-15 23:05 Message: Logged In: YES user_id=149084 Bug 1479785 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540892&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:28:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:28:18 -0700 Subject: [Patches] [ python-Patches-1540385 ] tarfile __slots__ addition Message-ID: Patches item #1540385, was opened at 2006-08-15 06:47 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile __slots__ addition Initial Comment: Quicky mod, use __slots__ for TarInfo objects in tarfile module; lot of slots, but reduces memory by around 33% in testing. Pardon the delay in submitting; would like to see it in 2.5, but also well aware it's pushing it time wise. ---------------------------------------------------------------------- Comment By: Lars Gustäbel (gustaebel) Date: 2006-08-16 15:28 Message: Logged In: YES user_id=642936 If you had run the test suite you would have noticed that there are still some names missing: buf, sparse and _link_target. Please adjust the patch. I cannot really estimate the implications of this patch. I think in terms of memory use it is reasonable to add __slots__ to Tarinfo objects because they can appear in hordes of thousands sometimes. But it could break some code, too. OTOH it is easy to reverse ;-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-08-15 08:55 Message: Logged In: YES user_id=21627 It definitely can't get into 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 From noreply at sourceforge.net Wed Aug 16 17:40:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 08:40:22 -0700 Subject: [Patches] [ python-Patches-1540869 ] CodeContext visibility Message-ID: Patches item #1540869, was opened at 2006-08-15 22:20 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 Please note that this 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.6 Status: Open Resolution: Later Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext visibility Initial Comment: CodeContext hardcodes several constants; these two in particular make it difficult to visually separate the "context" from the top of the regular code. Ideally, the measurement would change to something like em or ex, but ... this was an improvement. Note that the separation is explicitly there in the code already; it just doesn't work with the current constants. If the Relesae Manager decides to delay it to 2.6 (or backport to 2.4), I won't object. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-08-16 18:40 Message: Logged In: YES user_id=1330769 I originally wrote the code with those constants. I used those constants because I specifically wanted to line up the CodeContext code with the code in the main window, for easier reading. Your patch does the exact opposite - it pushes the CodeContext code way to the right. IMO, since the purpose of CodeContext is to have the current scope easily seen, having the code aligned is vital. You may prefer dis-alignment because it's easier to tell CodeContext apart, but that's just a personal preference, and IMO not something that should be the default behavior of IDLE. Personally, I find that CodeContext's different background color is more than enough to distinguish it from the main editor window. CodeContext's background and foreground colors are configurable (in config-extensions), you can always choose colors you like better. Tal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 From noreply at sourceforge.net Wed Aug 16 18:15:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 09:15:35 -0700 Subject: [Patches] [ python-Patches-1541412 ] most missing from Windows distribution Message-ID: Patches item #1541412, was opened at 2006-08-16 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=1541412&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: most missing from Windows distribution Initial Comment: The windows distribution (I'm currently looking at 2.5b3) does not contain a Demo directory, and the Tools directory contains only five packages (i18n, pynche, Scripts, versioncheck, webchecker) SVN Head lists 20 directories under Demo and 17 under Tools. At a first pass, all except tools/audiopy (Solaris specific) are relevant on Windows, and some tools (such as freeze, msi) even have windows-specific code. I've marked it 2.5 because consistency with other platforms seems like a bugfix, even if it does introduce new features to windows. (And note that it only adds new files that are not on the standard path, so no old behavior should change.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541412&group_id=5470 From noreply at sourceforge.net Wed Aug 16 18:17:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 09:17:54 -0700 Subject: [Patches] [ python-Patches-1541412 ] most missing from Windows distribution Message-ID: Patches item #1541412, was opened at 2006-08-16 12:15 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541412&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: most missing from Windows distribution Initial Comment: The windows distribution (I'm currently looking at 2.5b3) does not contain a Demo directory, and the Tools directory contains only five packages (i18n, pynche, Scripts, versioncheck, webchecker) SVN Head lists 20 directories under Demo and 17 under Tools. At a first pass, all except tools/audiopy (Solaris specific) are relevant on Windows, and some tools (such as freeze, msi) even have windows-specific code. I've marked it 2.5 because consistency with other platforms seems like a bugfix, even if it does introduce new features to windows. (And note that it only adds new files that are not on the standard path, so no old behavior should change.) ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-16 12:17 Message: Logged In: YES user_id=764593 wrong tracker ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541412&group_id=5470 From noreply at sourceforge.net Wed Aug 16 19:18:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 10:18:19 -0700 Subject: [Patches] [ python-Patches-1540869 ] CodeContext visibility Message-ID: Patches item #1540869, was opened at 2006-08-15 15:20 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 Please note that this 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.6 Status: Open Resolution: Later Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext visibility Initial Comment: CodeContext hardcodes several constants; these two in particular make it difficult to visually separate the "context" from the top of the regular code. Ideally, the measurement would change to something like em or ex, but ... this was an improvement. Note that the separation is explicitly there in the code already; it just doesn't work with the current constants. If the Relesae Manager decides to delay it to 2.6 (or backport to 2.4), I won't object. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-16 13:18 Message: Logged In: YES user_id=764593 ahh ... I hadn't even noticed the (effectively one- character) horizontal change. The change I aimed for (which I thought was the goal of the pad frame) was a slight *vertical* separation between the parts. So definately not until 2.6, and hopefully the eventual replacement will be better than what I posted here. Thank you for the clarification. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-08-16 11:40 Message: Logged In: YES user_id=1330769 I originally wrote the code with those constants. I used those constants because I specifically wanted to line up the CodeContext code with the code in the main window, for easier reading. Your patch does the exact opposite - it pushes the CodeContext code way to the right. IMO, since the purpose of CodeContext is to have the current scope easily seen, having the code aligned is vital. You may prefer dis-alignment because it's easier to tell CodeContext apart, but that's just a personal preference, and IMO not something that should be the default behavior of IDLE. Personally, I find that CodeContext's different background color is more than enough to distinguish it from the main editor window. CodeContext's background and foreground colors are configurable (in config-extensions), you can always choose colors you like better. Tal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 From noreply at sourceforge.net Wed Aug 16 19:19:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 10:19:23 -0700 Subject: [Patches] [ python-Patches-1540869 ] CodeContext visibility Message-ID: Patches item #1540869, was opened at 2006-08-15 15:20 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 Please note that this 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.6 Status: Open Resolution: Later Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext visibility Initial Comment: CodeContext hardcodes several constants; these two in particular make it difficult to visually separate the "context" from the top of the regular code. Ideally, the measurement would change to something like em or ex, but ... this was an improvement. Note that the separation is explicitly there in the code already; it just doesn't work with the current constants. If the Relesae Manager decides to delay it to 2.6 (or backport to 2.4), I won't object. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-16 13:19 Message: Logged In: YES user_id=764593 ahh ... I hadn't even noticed the (effectively one- character) horizontal change. The change I aimed for (which I thought was the goal of the pad frame) was a slight *vertical* separation between the parts. So definately not until 2.6, and hopefully the eventual replacement will be better than what I posted here. Thank you for the clarification. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-16 13:18 Message: Logged In: YES user_id=764593 ahh ... I hadn't even noticed the (effectively one- character) horizontal change. The change I aimed for (which I thought was the goal of the pad frame) was a slight *vertical* separation between the parts. So definately not until 2.6, and hopefully the eventual replacement will be better than what I posted here. Thank you for the clarification. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-08-16 11:40 Message: Logged In: YES user_id=1330769 I originally wrote the code with those constants. I used those constants because I specifically wanted to line up the CodeContext code with the code in the main window, for easier reading. Your patch does the exact opposite - it pushes the CodeContext code way to the right. IMO, since the purpose of CodeContext is to have the current scope easily seen, having the code aligned is vital. You may prefer dis-alignment because it's easier to tell CodeContext apart, but that's just a personal preference, and IMO not something that should be the default behavior of IDLE. Personally, I find that CodeContext's different background color is more than enough to distinguish it from the main editor window. CodeContext's background and foreground colors are configurable (in config-extensions), you can always choose colors you like better. Tal ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540869&group_id=5470 From noreply at sourceforge.net Wed Aug 16 23:28:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 14:28:00 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 17:27 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=1541585&group_id=5470 Please note that this 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 Submitted By: Simon Law (sfllaw) Assigned to: Nobody/Anonymous (nobody) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Wed Aug 16 23:29:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 14:29:38 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 14:27 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this 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: 8 Submitted By: Simon Law (sfllaw) Assigned to: Nobody/Anonymous (nobody) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Wed Aug 16 23:48:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 14:48:01 -0700 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 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-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 Thu Aug 17 12:44:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 03:44:28 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 19: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=1541863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Thu Aug 17 12:45:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 03:45:25 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 19:44 Message generated for change (Settings changed) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 Please note that this 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: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Thu Aug 17 16:27:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 07:27:29 -0700 Subject: [Patches] [ python-Patches-1542019 ] patch in bug 1542016 Message-ID: Patches item #1542019, was opened at 2006-08-17 16:27 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=1542019&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: patch in bug 1542016 Initial Comment: As commented in bug 1542016, reporting via sys.callstats() is missing the PCALL_POP values, due probably to a typo when this last profile condition was added. This patch makes it behave. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542019&group_id=5470 From noreply at sourceforge.net Thu Aug 17 16:41:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 07:41:57 -0700 Subject: [Patches] [ python-Patches-1542019 ] patch in bug 1542016 Message-ID: Patches item #1542019, was opened at 2006-08-17 14:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542019&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: patch in bug 1542016 Initial Comment: As commented in bug 1542016, reporting via sys.callstats() is missing the PCALL_POP values, due probably to a typo when this last profile condition was added. This patch makes it behave. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 14:41 Message: Logged In: YES user_id=849994 As the patch is already in bug #1542016 (and it is very small), I'm closing this again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542019&group_id=5470 From noreply at sourceforge.net Thu Aug 17 19:13:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 10:13:31 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 03:44 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Thu Aug 17 21:00:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 12:00:48 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 19:44 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-18 04:00 Message: Logged In: YES user_id=1200846 Sorry, my explanation was wrong. timestamp == X and _last_timestamp != X: timestamp remains X, and _last_timestamp becomes X timestamp == X: (again) timestamp == _last_timestamp, so timestamp and _last_timestamp becomes X + 1. timestamp == X: (again) timestamp != _last_timestamp, so timestamp remains X (duplicated timestamp!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Thu Aug 17 22:05:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 13:05:55 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 12:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Hirokazu Yamamoto (ocean-city) >Assigned to: Neal Norwitz (nnorwitz) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-17 22:05 Message: Logged In: YES user_id=21627 >From inspection, the patch looks right to me (although i haven't tested it). I think it should go into 2.5. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-17 21:00 Message: Logged In: YES user_id=1200846 Sorry, my explanation was wrong. timestamp == X and _last_timestamp != X: timestamp remains X, and _last_timestamp becomes X timestamp == X: (again) timestamp == _last_timestamp, so timestamp and _last_timestamp becomes X + 1. timestamp == X: (again) timestamp != _last_timestamp, so timestamp remains X (duplicated timestamp!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Fri Aug 18 05:36:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 20:36:12 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 03:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 Please note that this 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: 9 Submitted By: Hirokazu Yamamoto (ocean-city) >Assigned to: Martin v. L?wis (loewis) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-17 20:36 Message: Logged In: YES user_id=33168 Thanks for the patch! Assuming this fixes the problem on Windows, someone please test this and check it in. Don't forget, head and 2.5 branch. Needs updates to Misc/{NEWS,ACKS} ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-17 13:05 Message: Logged In: YES user_id=21627 >From inspection, the patch looks right to me (although i haven't tested it). I think it should go into 2.5. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-17 12:00 Message: Logged In: YES user_id=1200846 Sorry, my explanation was wrong. timestamp == X and _last_timestamp != X: timestamp remains X, and _last_timestamp becomes X timestamp == X: (again) timestamp == _last_timestamp, so timestamp and _last_timestamp becomes X + 1. timestamp == X: (again) timestamp != _last_timestamp, so timestamp remains X (duplicated timestamp!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Fri Aug 18 05:48:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 20:48:22 -0700 Subject: [Patches] [ python-Patches-1541863 ] work around clocks with low resolution (uuid.py) Message-ID: Patches item #1541863, was opened at 2006-08-17 12:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 Please note that this 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: 8 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Martin v. L?wis (loewis) Summary: work around clocks with low resolution (uuid.py) Initial Comment: This patch improves workaround clocks with low resolution yielding duplicate UUIDs. (rev51307) Currently, windows buildbot is failing due to this bug. http://www.python.org/dev/buildbot/trunk/x86%20XP%20trunk/builds/1390/step-test/0 Traceback (most recent call last): File "C:\buildbot_py25\trunk.mcintyre-windows\build\lib\test\test_uuid.py", line 381, in test_uuid1 equal(len(uuids.keys()), 1000) AssertionError: 998 != 1000 This happens because on this code (Lib/uuid.py), if timestamp == _last_timestamp: timestamp += 1 _last_timestamp = timestamp if timestamp is same value more than 3 times.... timestamp == X and _last_timestamp != X: timestamp <- X + 1 and _last_timestamp <- X + 1 timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X timestamp == X: (again) timestamp != _last_timestamp, so timestamp is still X (duplicated timestamp!) I fixed this bug with attached patch. # also fixed probably typo in test_uuid.py ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-18 05:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r51353 and r51354. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 05:36 Message: Logged In: YES user_id=33168 Thanks for the patch! Assuming this fixes the problem on Windows, someone please test this and check it in. Don't forget, head and 2.5 branch. Needs updates to Misc/{NEWS,ACKS} ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-17 22:05 Message: Logged In: YES user_id=21627 >From inspection, the patch looks right to me (although i haven't tested it). I think it should go into 2.5. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-17 21:00 Message: Logged In: YES user_id=1200846 Sorry, my explanation was wrong. timestamp == X and _last_timestamp != X: timestamp remains X, and _last_timestamp becomes X timestamp == X: (again) timestamp == _last_timestamp, so timestamp and _last_timestamp becomes X + 1. timestamp == X: (again) timestamp != _last_timestamp, so timestamp remains X (duplicated timestamp!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541863&group_id=5470 From noreply at sourceforge.net Fri Aug 18 09:27:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 00:27:49 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 00:27 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=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 8 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Fri Aug 18 11:44:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 02:44:24 -0700 Subject: [Patches] [ python-Patches-1507247 ] tarfile extraction does not honor umask Message-ID: Patches item #1507247, was opened at 2006-06-16 15:11 Message generated for change (Comment added) made by faik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile extraction does not honor umask Initial Comment: If the upperdirs in the member file's pathname does not exist. tarfile creates those paths with 0777 permission bits and does not honor umask. This patch uses umask to set the ti.mode of the created directory for later usage in chmod. --- tarfile.py (revision 46993) +++ tarfile.py (working copy) @@ -1560,7 +1560,9 @@ ti = TarInfo() ti.name = upperdirs ti.type = DIRTYPE - ti.mode = 0777 + umask = os.umask(0) + ti.mode = 0777 - umask + os.umask(umask) ti.mtime = tarinfo.mtime ti.uid = tarinfo.uid ti.gid = tarinfo.gid ---------------------------------------------------------------------- >Comment By: Faik Uygur (faik) Date: 2006-08-18 12:44 Message: Logged In: YES user_id=1541018 Above patch is wrong. The correct one is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507247&group_id=5470 From noreply at sourceforge.net Fri Aug 18 13:03:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 04:03:33 -0700 Subject: [Patches] [ python-Patches-1542544 ] Improve dynamic linking support on AIX Message-ID: Patches item #1542544, was opened at 2006-08-18 13:03 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=1542544&group_id=5470 Please note that this 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 Submitted By: Göran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: Improve dynamic linking support on AIX Initial Comment: Python 2.4.3 does not produce a shared python library on AIX even with the --enable-shared flag. The addition of the LDLIBRARY and RUNSHARED variables in the patch should fix this. If I create my own version of the Python engine in a shared library, that version is not able to load any modules. My understanding is that this is because the import directives used when building the modules say that symbols should come from ".", which means the main program. In the patch I replace that with "..", which should look both in the main program and loaded shared libraries. Strictly speaking you could argue that these are two different problems, and could motivate two separate reports. But since they are closely related, both having to do with dynamic linking on AIX, I submit them together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542544&group_id=5470 From noreply at sourceforge.net Fri Aug 18 16:48:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 07:48:51 -0700 Subject: [Patches] [ python-Patches-1542681 ] Tweak pydoc to speak about with and CONTEXTMANAGERS Message-ID: Patches item #1542681, was opened at 2006-08-18 16: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=1542681&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: Tweak pydoc to speak about with and CONTEXTMANAGERS Initial Comment: Just a first go to having pydoc speaking about 2.5 features. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542681&group_id=5470 From noreply at sourceforge.net Sat Aug 19 03:44:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 18:44:45 -0700 Subject: [Patches] [ python-Patches-1542946 ] Fix the vc8 solution files Message-ID: Patches item #1542946, was opened at 2006-08-18 18:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: baus (cbaus) Assigned to: Nobody/Anonymous (nobody) Summary: Fix the vc8 solution files Initial Comment: VC8 isn't linking out of the box. Added typesmodule to pythoncore project and added _socket module to the python solution file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542946&group_id=5470 From noreply at sourceforge.net Sat Aug 19 03:48:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 18:48:11 -0700 Subject: [Patches] [ python-Patches-1542948 ] urllib2 regression Message-ID: Patches item #1542948, was opened at 2006-08-19 02: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=1542948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 regression Initial Comment: Patch 1459963 (applied in 50842) needlessly breaks the old (albeit undocumented) interface of direct access to request.headers (which existed prior to the introduction of method. That patch changes the case of the keys of the request.headers dictionary. That seems guaranteed to break existing code. The attached patch reverts 50842's changes to urllib2 (it does not revert the changes to urllib) and fixes the reported issue with a one-line fix in AbstractHTTPHandler (.title()-case the HTTP headers before sending them to httplib). That fix is also more localised to HTTP -- urllib2 knows about other protocols too. This patch also corrects a mis-wording in Misc/NEWS: the old case convention was not strictly incorrect (according to RFC 2616), but just did not follow the usual title-case convention. If the original patch was applied to the 2.4 maintenance branch, I guess this patch should be applied there too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 From noreply at sourceforge.net Sat Aug 19 03:50:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 18:50:54 -0700 Subject: [Patches] [ python-Patches-1542948 ] urllib2 regression Message-ID: Patches item #1542948, was opened at 2006-08-19 02:48 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 regression Initial Comment: Patch 1459963 (applied in 50842) needlessly breaks the old (albeit undocumented) interface of direct access to request.headers (which existed prior to the introduction of method. That patch changes the case of the keys of the request.headers dictionary. That seems guaranteed to break existing code. The attached patch reverts 50842's changes to urllib2 (it does not revert the changes to urllib) and fixes the reported issue with a one-line fix in AbstractHTTPHandler (.title()-case the HTTP headers before sending them to httplib). That fix is also more localised to HTTP -- urllib2 knows about other protocols too. This patch also corrects a mis-wording in Misc/NEWS: the old case convention was not strictly incorrect (according to RFC 2616), but just did not follow the usual title-case convention. If the original patch was applied to the 2.4 maintenance branch, I guess this patch should be applied there too. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2006-08-19 02:50 Message: Logged In: YES user_id=261020 s/(which existed prior to the introduction of method/(which existed prior to the introduction of the .get_header() &c. methods)/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 From noreply at sourceforge.net Sat Aug 19 05:23:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 20:23:19 -0700 Subject: [Patches] [ python-Patches-1540470 ] Patches for OpenBSD 4.0 Message-ID: Patches item #1540470, was opened at 2006-08-15 01:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for OpenBSD 4.0 Initial Comment: Hi, There are several points in the Python-2.5b3 code that need to be modified to properly support OpenBSD 4.x. This is mostly because of a dependence on sys.platform returning "openbsd3", which is no longer true for OpenBSD CVS - OpenBSD 4.0 is in beta right now, to be released in a couple of months. The attached patch (against SVN head) fixes this. It would be great if this can make it in for Python-2.5. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 20:23 Message: Logged In: YES user_id=33168 Did you confirm that each of these hunks are necessary with 4.0 or did you just copy anywhere there was openbsd3 and add openbsd4? Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 04:13 Message: Logged In: YES user_id=849994 Speaking of OpenBSD, Gentoo has an additional patch to compile for OpenBSD, I'll attach it here without looking into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 From noreply at sourceforge.net Sat Aug 19 07:25:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 22:25:09 -0700 Subject: [Patches] [ python-Patches-1540470 ] Patches for OpenBSD 4.0 Message-ID: Patches item #1540470, was opened at 2006-08-15 18:37 Message generated for change (Comment added) made by djmdjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for OpenBSD 4.0 Initial Comment: Hi, There are several points in the Python-2.5b3 code that need to be modified to properly support OpenBSD 4.x. This is mostly because of a dependence on sys.platform returning "openbsd3", which is no longer true for OpenBSD CVS - OpenBSD 4.0 is in beta right now, to be released in a couple of months. The attached patch (against SVN head) fixes this. It would be great if this can make it in for Python-2.5. ---------------------------------------------------------------------- >Comment By: Damien Miller (djmdjm) Date: 2006-08-19 15:25 Message: Logged In: YES user_id=1359232 No, these patches are required to build and pass regress on OpenBSD 4.0. It wasn't a simple search and replace exercise. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 13:23 Message: Logged In: YES user_id=33168 Did you confirm that each of these hunks are necessary with 4.0 or did you just copy anywhere there was openbsd3 and add openbsd4? Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 21:13 Message: Logged In: YES user_id=849994 Speaking of OpenBSD, Gentoo has an additional patch to compile for OpenBSD, I'll attach it here without looking into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 From noreply at sourceforge.net Sat Aug 19 07:27:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 22:27:48 -0700 Subject: [Patches] [ python-Patches-1540470 ] Patches for OpenBSD 4.0 Message-ID: Patches item #1540470, was opened at 2006-08-15 01:37 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Damien Miller (djmdjm) >Assigned to: Neal Norwitz (nnorwitz) Summary: Patches for OpenBSD 4.0 Initial Comment: Hi, There are several points in the Python-2.5b3 code that need to be modified to properly support OpenBSD 4.x. This is mostly because of a dependence on sys.platform returning "openbsd3", which is no longer true for OpenBSD CVS - OpenBSD 4.0 is in beta right now, to be released in a couple of months. The attached patch (against SVN head) fixes this. It would be great if this can make it in for Python-2.5. ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-18 22:25 Message: Logged In: YES user_id=1359232 No, these patches are required to build and pass regress on OpenBSD 4.0. It wasn't a simple search and replace exercise. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 20:23 Message: Logged In: YES user_id=33168 Did you confirm that each of these hunks are necessary with 4.0 or did you just copy anywhere there was openbsd3 and add openbsd4? Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-15 04:13 Message: Logged In: YES user_id=849994 Speaking of OpenBSD, Gentoo has an additional patch to compile for OpenBSD, I'll attach it here without looking into it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540470&group_id=5470 From noreply at sourceforge.net Sat Aug 19 07:35:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 22:35:41 -0700 Subject: [Patches] [ python-Patches-1542948 ] urllib2 regression Message-ID: Patches item #1542948, was opened at 2006-08-18 18:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 regression Initial Comment: Patch 1459963 (applied in 50842) needlessly breaks the old (albeit undocumented) interface of direct access to request.headers (which existed prior to the introduction of method. That patch changes the case of the keys of the request.headers dictionary. That seems guaranteed to break existing code. The attached patch reverts 50842's changes to urllib2 (it does not revert the changes to urllib) and fixes the reported issue with a one-line fix in AbstractHTTPHandler (.title()-case the HTTP headers before sending them to httplib). That fix is also more localised to HTTP -- urllib2 knows about other protocols too. This patch also corrects a mis-wording in Misc/NEWS: the old case convention was not strictly incorrect (according to RFC 2616), but just did not follow the usual title-case convention. If the original patch was applied to the 2.4 maintenance branch, I guess this patch should be applied there too. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 22:35 Message: Logged In: YES user_id=33168 I would like to see additional tests to ensure something like this doesn't happen again. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-18 18:50 Message: Logged In: YES user_id=261020 s/(which existed prior to the introduction of method/(which existed prior to the introduction of the .get_header() &c. methods)/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 From noreply at sourceforge.net Sat Aug 19 09:48:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 00:48:20 -0700 Subject: [Patches] [ python-Patches-1540329 ] Backports from trunk to release24-maint Message-ID: Patches item #1540329, was opened at 2006-08-15 01:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: flub (bruynooghef) Assigned to: Nobody/Anonymous (nobody) Summary: Backports from trunk to release24-maint Initial Comment: Backports of _hotshot.c only: r41768, r45341, r51218 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-19 07:48 Message: Logged In: YES user_id=849994 Applied in rev. 51405. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540329&group_id=5470 From noreply at sourceforge.net Sat Aug 19 10:04:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 01:04:09 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 07:27 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 8 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-19 08:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Sat Aug 19 17:08:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 08:08:44 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 00:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 8 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 08:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 01:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Sat Aug 19 19:15:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 10:15:50 -0700 Subject: [Patches] [ python-Patches-1542948 ] urllib2 regression Message-ID: Patches item #1542948, was opened at 2006-08-19 02:48 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 regression Initial Comment: Patch 1459963 (applied in 50842) needlessly breaks the old (albeit undocumented) interface of direct access to request.headers (which existed prior to the introduction of method. That patch changes the case of the keys of the request.headers dictionary. That seems guaranteed to break existing code. The attached patch reverts 50842's changes to urllib2 (it does not revert the changes to urllib) and fixes the reported issue with a one-line fix in AbstractHTTPHandler (.title()-case the HTTP headers before sending them to httplib). That fix is also more localised to HTTP -- urllib2 knows about other protocols too. This patch also corrects a mis-wording in Misc/NEWS: the old case convention was not strictly incorrect (according to RFC 2616), but just did not follow the usual title-case convention. If the original patch was applied to the 2.4 maintenance branch, I guess this patch should be applied there too. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2006-08-19 18:15 Message: Logged In: YES user_id=261020 Quite right, here's a patch with the missing test. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 06:35 Message: Logged In: YES user_id=33168 I would like to see additional tests to ensure something like this doesn't happen again. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-19 02:50 Message: Logged In: YES user_id=261020 s/(which existed prior to the introduction of method/(which existed prior to the introduction of the .get_header() &c. methods)/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 From noreply at sourceforge.net Sun Aug 20 15:15:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 06:15:55 -0700 Subject: [Patches] [ python-Patches-1542948 ] urllib2 regression Message-ID: Patches item #1542948, was opened at 2006-08-19 01:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 regression Initial Comment: Patch 1459963 (applied in 50842) needlessly breaks the old (albeit undocumented) interface of direct access to request.headers (which existed prior to the introduction of method. That patch changes the case of the keys of the request.headers dictionary. That seems guaranteed to break existing code. The attached patch reverts 50842's changes to urllib2 (it does not revert the changes to urllib) and fixes the reported issue with a one-line fix in AbstractHTTPHandler (.title()-case the HTTP headers before sending them to httplib). That fix is also more localised to HTTP -- urllib2 knows about other protocols too. This patch also corrects a mis-wording in Misc/NEWS: the old case convention was not strictly incorrect (according to RFC 2616), but just did not follow the usual title-case convention. If the original patch was applied to the 2.4 maintenance branch, I guess this patch should be applied there too. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 13:15 Message: Logged In: YES user_id=849994 Applied as rev. 51416, 51417 (2.5) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-19 17:15 Message: Logged In: YES user_id=261020 Quite right, here's a patch with the missing test. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 05:35 Message: Logged In: YES user_id=33168 I would like to see additional tests to ensure something like this doesn't happen again. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-19 01:50 Message: Logged In: YES user_id=261020 s/(which existed prior to the introduction of method/(which existed prior to the introduction of the .get_header() &c. methods)/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542948&group_id=5470 From noreply at sourceforge.net Mon Aug 21 14:03:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 05:03:31 -0700 Subject: [Patches] [ python-Patches-1543897 ] tarfile.py: fix for bug 1543303 Message-ID: Patches item #1543897, was opened at 2006-08-21 14:03 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=1543897&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gustäbel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py: fix for bug 1543303 Initial Comment: see comments in bug #1543303. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1543897&group_id=5470 From noreply at sourceforge.net Mon Aug 21 20:49:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 11:49:16 -0700 Subject: [Patches] [ python-Patches-1543897 ] tarfile.py: fix for bug 1543303 Message-ID: Patches item #1543897, was opened at 2006-08-21 05:03 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1543897&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gustäbel (gustaebel) >Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile.py: fix for bug 1543303 Initial Comment: see comments in bug #1543303. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 11:49 Message: Logged In: YES user_id=33168 Committed revision 51432. (2.6) 51436 (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1543897&group_id=5470 From noreply at sourceforge.net Mon Aug 21 21:37:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 12:37:49 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 09:27 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 8 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-08-21 21:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 17:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 10:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Mon Aug 21 21:48:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 12:48:08 -0700 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 00:27 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler >Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 12:48 Message: Logged In: YES user_id=33168 Committed revision 51439. (2.6) Thomas Wouters thinks this is fine to go in 2.5. I'll leave open for now until we decide what to do. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-21 12:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 08:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 01:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Tue Aug 22 00:22:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 15:22:20 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 14:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this 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: Fixed Priority: 8 Submitted By: Simon Law (sfllaw) >Assigned to: Neal Norwitz (nnorwitz) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 15:22 Message: Logged In: YES user_id=33168 Committed revision 51448. (2.6) Committed revision 51450. (2.5) Someone should backport to 2.4, leaving open until then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Tue Aug 22 00:22:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 15:22:40 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 14:27 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this 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: Fixed >Priority: 7 Submitted By: Simon Law (sfllaw) Assigned to: Neal Norwitz (nnorwitz) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 15:22 Message: Logged In: YES user_id=33168 Committed revision 51448. (2.6) Committed revision 51450. (2.5) Someone should backport to 2.4, leaving open until then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Tue Aug 22 01:24:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 16:24:26 -0700 Subject: [Patches] [ python-Patches-1544279 ] Socket module is not thread-safe Message-ID: Patches item #1544279, was opened at 2006-08-21 16: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=1544279&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Socket module is not thread-safe Initial Comment: The socket module make a great effort to be thread- safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo () is not protected with netdb mutex on systems that don't have thread- safe resolver. P.S. This is very serious problem for us. For some reason my previous patch submission has been downgraded to bug report and forgotten completely, so that I am re-submitting. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544279&group_id=5470 From noreply at sourceforge.net Tue Aug 22 01:42:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 16:42:48 -0700 Subject: [Patches] [ python-Patches-1544279 ] Socket module is not thread-safe Message-ID: Patches item #1544279, was opened at 2006-08-22 01:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544279&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Maxim Sobolev (sobomax) >Assigned to: Martin v. L?wis (loewis) Summary: Socket module is not thread-safe Initial Comment: The socket module make a great effort to be thread- safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo () is not protected with netdb mutex on systems that don't have thread- safe resolver. P.S. This is very serious problem for us. For some reason my previous patch submission has been downgraded to bug report and forgotten completely, so that I am re-submitting. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-22 01:42 Message: Logged In: YES user_id=21627 Sorry about forgetting your patch. Will look at it again for 2.5.1. P.S. The previous issue was #1467080. It wasn't "downgraded to bug report"; instead, you submitted it as a bug report to start with. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544279&group_id=5470 From noreply at sourceforge.net Tue Aug 22 10:26:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 01:26:33 -0700 Subject: [Patches] [ python-Patches-1541585 ] buffer overrun in repr() for unicode strings Message-ID: Patches item #1541585, was opened at 2006-08-16 21:27 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 7 Submitted By: Simon Law (sfllaw) Assigned to: Neal Norwitz (nnorwitz) Summary: buffer overrun in repr() for unicode strings Initial Comment: From https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56633 Benjamin C. Wiley Sittler reports: hi, i discovered a bug yesterday in repr() for unicode strings. this causes an unpatched non-debug wide (UTF-32/UCS-4) build of python to abort: python2.4 -c 'assert(repr(u"\U00010000" * 39 + u"\uffff" * 4096)) == (repr(u"\U00010000" * 39 + u"\uffff" * 4096))' the problem is fixed by a change to unicodeobject.c. in the process of fixing it i also found and fixed another bug in repr() on UCS-4 python builds -- previously paired unicode surrogates were being repr()'ed as a single "character" even though they are not treated as such by a UCS-4 python build -- i.e. eval(repr(u'\ud800\udc00')) != u'\ud800\udc00' in an unpatched UCS-4 build. Package: python2.4 Version: 2.4.3-7ubuntu2 Severity: important when i run this command: python -c "repr(u'\u24ea\u059c\u200a\U0001d77e\uff07\u202f\u0747\u202f \U0001d56b\U0001d5b9\U0001d4e9\u20052\u14bf\U0001d7f8\u200a\U0001d795 \U0001d6e7Z\u2006\u2002\U0001d50a\uff27\u13c0\u2000\uff16\u0411\uff16 \U0001d7e7\uff4c\u2006\u2001\ufe39\u2008\u0313]\u2008\u3014\u3015')" python aborts with the following backtrace and memory dump: *** glibc detected *** python: realloc(): invalid next size: 0x081521e8 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e8acd4] /lib/tls/i686/cmov/libc.so.6(__libc_realloc+0xff)[0xb7e8cc5f] python(_PyString_Resize+0x80)[0x8082b4b] python[0x80991f7] python(PyObject_Repr+0x58)[0x807d1fd] python(PyEval_EvalFrame+0x4b37)[0x80b5270] python(PyEval_EvalCodeEx+0x836)[0x80b65d6] python(PyEval_EvalCode+0x57)[0x80b6640] python(PyRun_SimpleStringFlags+0xa8)[0x80d8b7c] python(Py_Main+0x685)[0x8055862] python(main+0x22)[0x80550e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd8)[0xb7e378b8] python[0x8055041] ======= Memory map: ======== 08048000-0811a000 r-xp 00000000 08:03 622736 /usr/bin/python2.4 0811a000-0813b000 rw-p 000d1000 08:03 622736 /usr/bin/python2.4 0813b000-081b5000 rw-p 0813b000 00:00 0 [heap] b7c00000-b7c21000 rw-p b7c00000 00:00 0 b7c21000-b7d00000 ---p b7c21000 00:00 0 b7d40000-b7d4a000 r-xp 00000000 08:03 376899 /lib/libgcc_s.so.1 b7d4a000-b7d4b000 rw-p 00009000 08:03 376899 /lib/libgcc_s.so.1 b7d68000-b7d9b000 r--p 00000000 08:03 82634 /usr/lib/locale/en_US.utf8/LC_CTYPE b7d9b000-b7d9e000 r-xp 00000000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9e000-b7d9f000 rw-p 00003000 08:03 625529 /usr/lib/python2.4/lib-dynload/_locale.so b7d9f000-b7e22000 rw-p b7d9f000 00:00 0 b7e22000-b7f51000 r-xp 00000000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f51000-b7f53000 r--p 0012e000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f53000-b7f55000 rw-p 00130000 08:03 66543 /lib/tls/i686/cmov/libc-2.4.so b7f55000-b7f58000 rw-p b7f55000 00:00 0 b7f58000-b7f7c000 r-xp 00000000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7c000-b7f7e000 rw-p 00023000 08:03 66547 /lib/tls/i686/cmov/libm-2.4.so b7f7e000-b7f80000 r-xp 00000000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f80000-b7f82000 rw-p 00001000 08:03 68161 /lib/tls/i686/cmov/libutil-2.4.so b7f82000-b7f83000 rw-p b7f82000 00:00 0 b7f83000-b7f85000 r-xp 00000000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f85000-b7f87000 rw-p 00001000 08:03 66546 /lib/tls/i686/cmov/libdl-2.4.so b7f87000-b7f96000 r-xp 00000000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f96000-b7f98000 rw-p 0000f000 08:03 68156 /lib/tls/i686/cmov/libpthread-2.4.so b7f98000-b7f9a000 rw-p b7f98000 00:00 0 b7fb0000-b7fb7000 r--s 00000000 08:03 2130015 /usr/lib/gconv/gconv-modules.cache b7fb7000-b7fb9000 rw-p b7fb7000 00:00 0 b7fb9000-b7fd2000 r-xp 00000000 08:03 2737127 /lib/ld-2.4.so b7fd2000-b7fd4000 rw-p 00018000 08:03 2737127 /lib/ld-2.4.so bf99b000-bf9b3000 rw-p bf99b000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Aborted ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 08:26 Message: Logged In: YES user_id=849994 Applied to 2.4 in revision 51466. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 22:22 Message: Logged In: YES user_id=33168 Committed revision 51448. (2.6) Committed revision 51450. (2.5) Someone should backport to 2.4, leaving open until then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1541585&group_id=5470 From noreply at sourceforge.net Tue Aug 22 23:36:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 14:36:21 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14: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=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Tue Aug 22 23:44:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 14:44:52 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Wed Aug 23 00:10:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 15:10:01 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Wed Aug 23 03:35:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 18:35:50 -0700 Subject: [Patches] [ python-Patches-1545011 ] Fixes SocketServer Bug 1531963 Message-ID: Patches item #1545011, was opened at 2006-08-23 01: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=1545011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Damon Kohler (damonkohler) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes SocketServer Bug 1531963 Initial Comment: Bug 1531963 is fixed by setting SocketServer.server_address = SocketServer.socket.getsockname() when the socket is bound. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 From noreply at sourceforge.net Wed Aug 23 15:01:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 06:01:54 -0700 Subject: [Patches] [ python-Patches-1545262 ] new splicetee module Message-ID: Patches item #1545262, was opened at 2006-08-23 15:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545262&group_id=5470 Please note that this 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 Submitted By: Omar AitMous (oaitmous) Assigned to: Nobody/Anonymous (nobody) Summary: new splicetee module Initial Comment: This module is an interface to the new splice()/tee() system calls under Linux Kernel 2.6.17 and higher. Splice allows one to transfer data from a stream to another within the kernel, without need for user-land involvement, while tee transfers data from a pipe to another without consuming the data on the first pipe. By combining both system calls, it is possible to actually do zero-copy movement of data from one or many sources to many destinations. For more information about splice() and tee() system call mechanisms : http://kerneltrap.org/node/6505 We would like to know if this is worth for inclusion in the standard Python distribution? What should be modified to make it more "compliant" to the python rules? This file will probably need to be updated to conform to python style standards. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545262&group_id=5470 From noreply at sourceforge.net Wed Aug 23 15:12:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 06:12:09 -0700 Subject: [Patches] [ python-Patches-1545275 ] new directio module Message-ID: Patches item #1545275, was opened at 2006-08-23 15: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=1545275&group_id=5470 Please note that this 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 Submitted By: Omar AitMous (oaitmous) Assigned to: Nobody/Anonymous (nobody) Summary: new directio module Initial Comment: This module is an interface to the open(),read(),write() and close() system calls on a Direct I/O context (O_DIRECT flag to the open() system call). The O_DIRECT flag allows to open a file in "direct" mode -- effectively bypassing the buffer-cache. This behaviour is generally not a good thing since it will strongly degrade performances, but it can be desirable for some purposes (benchmark, or optimized read of many concurrent video streams, for instance). A special interface is needed, since the read() system calls requires aligned buffers when used on O_DIRECT file descriptors. And since the flag O_DIRECT is not available with the os module, we decided to write this module. We would like to know if this is worth for inclusion in the standard Python distribution? What should be modified to make it more "compliant" to the python rules? This file will probably need to be updated to conform to python style standards. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545275&group_id=5470 From noreply at sourceforge.net Wed Aug 23 21:59:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 12:59:32 -0700 Subject: [Patches] [ python-Patches-1545507 ] ctypes and Win64 Message-ID: Patches item #1545507, was opened at 2006-08-23 21:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545507&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: ctypes and Win64 Initial Comment: The _ctypes extension is not built on Win64, because it is not yet ported to the AMD64 architecture. Since I'm working on win64 support in the ctypes SVN repo, chances are that this can be distributed and installed as standalone package for Python 2.5. To avoid problems with the installation, I recommend that the ctypes package in Lib/ctypes should *NOT* be included in the Python 2.5 AMD64 msi installer. The attached patch for Tools/msi/msi.py should implement this, although I cannot completely test it (I have not built the AMD64 version of sqlite3, no CHM file, and so on). Assigning to MvL because he builds the msi packages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545507&group_id=5470 From noreply at sourceforge.net Thu Aug 24 00:14:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 15:14:34 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-23 15:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 01:58:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 16:58:00 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 17:36 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 19:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 18:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 17:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 03:14:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 18:14:19 -0700 Subject: [Patches] [ python-Patches-1522038 ] Add some explication to PEP 3100 Message-ID: Patches item #1522038, was opened at 2006-07-13 12:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522038&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Brett Cannon (bcannon) Summary: Add some explication to PEP 3100 Initial Comment: The attached patch adds notes to PEP 3100 explaining why operator.isCallable() and operator.sequenceIncludes() are to be removed come Python 3000. This patch is in reaction to this python-3000 thread: http://mail.python.org/pipermail/python-3000/2006-July/002488.html ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:14 Message: Logged In: YES user_id=357491 rev. 51534 has the clarifications. Thanks, Collin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522038&group_id=5470 From noreply at sourceforge.net Thu Aug 24 18:20:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 09:20:54 -0700 Subject: [Patches] [ python-Patches-1546078 ] xrange that supports longs, etc Message-ID: Patches item #1546078, was opened at 2006-08-24 09: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=1546078&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: xrange that supports longs, etc Initial Comment: This patch is not ready for prime-time. It has various crap in it that needs to be cleaned up. I just wanted to put the current state up so we don't lose it. Once we decide on the direction this should take for 2.6 and 3k, I can finish off the patch. There is the change to rangeobject.c which contains the bulk of the changes. The bltinmodule.c change is only to support exporting the xrange iter to the python version of xrange. I've attached the xrange impl I've been playing with too. It may require some tweaks when you make little changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546078&group_id=5470 From noreply at sourceforge.net Thu Aug 24 19:14:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 10:14:25 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 10:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 16:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 15:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 19:37:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 10:37:48 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 17:36 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 13:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 13:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 19:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 18:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 17:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 19:49:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 10:49:20 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 17:36 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 13:49 Message: Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 13:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 13:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 19:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 18:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 17:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 23:23:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 14:23:09 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:23 Message: Logged In: YES user_id=357491 (2) I don't want to do that because it isn't like you can't call bind() multiple times. I would hate to get a Parameter object with some suggested argument value, and then while I had it have that value change because in another thread someone called bind() on the Signature object again. (3) Fair enough. Changed to your suggestion in my version. (4) OK, I see what you are getting at. Changed in my version. I still wish there was a different exception that I could use to flag that the binding didn't fail but that the code couldn't figure out one without being destructive. (5) Yep, that's a bug. I have a test case for it now and will work on fixing it. (7) Fair enough. Code changed and docstring updated. I will work on fixing the bug I have that you reported. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:49 Message: Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 10:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 16:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 15:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 23:34:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 14:34:37 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 17:36 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 17:34 Message: Logged In: YES user_id=764593 (4) Is there any reason you can't define a new exception type, perhaps as a subclass of TypeError? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 17:23 Message: Logged In: YES user_id=357491 (2) I don't want to do that because it isn't like you can't call bind() multiple times. I would hate to get a Parameter object with some suggested argument value, and then while I had it have that value change because in another thread someone called bind() on the Signature object again. (3) Fair enough. Changed to your suggestion in my version. (4) OK, I see what you are getting at. Changed in my version. I still wish there was a different exception that I could use to flag that the binding didn't fail but that the code couldn't figure out one without being destructive. (5) Yep, that's a bug. I have a test case for it now and will work on fixing it. (7) Fair enough. Code changed and docstring updated. I will work on fixing the bug I have that you reported. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 13:49 Message: Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 13:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 13:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 19:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 18:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 17:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Thu Aug 24 23:44:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 14:44:54 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:44 Message: Logged In: YES user_id=357491 OK, fixed the bug. Problem was that I had a bogus test that was testing for your example to fail. Oops. =) All fixed in the newest version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 14:34 Message: Logged In: YES user_id=764593 (4) Is there any reason you can't define a new exception type, perhaps as a subclass of TypeError? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:23 Message: Logged In: YES user_id=357491 (2) I don't want to do that because it isn't like you can't call bind() multiple times. I would hate to get a Parameter object with some suggested argument value, and then while I had it have that value change because in another thread someone called bind() on the Signature object again. (3) Fair enough. Changed to your suggestion in my version. (4) OK, I see what you are getting at. Changed in my version. I still wish there was a different exception that I could use to flag that the binding didn't fail but that the code couldn't figure out one without being destructive. (5) Yep, that's a bug. I have a test case for it now and will work on fixing it. (7) Fair enough. Code changed and docstring updated. I will work on fixing the bug I have that you reported. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:49 Message: Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 10:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 16:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 15:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Fri Aug 25 00:04:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 15:04:29 -0700 Subject: [Patches] [ python-Patches-1546288 ] crash in dict_equal Message-ID: Patches item #1546288, was opened at 2006-08-24 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neal Norwitz (nnorwitz) Summary: crash in dict_equal Initial Comment: I initially found this bug in the py3k branch, but it's reproducible in 2.5 as well (and probably older versions as well, as long as they have dict_equal()). It can be reproduced by using the attached patch to test_mutants.py. The problem is in this fragment in dict_equal(): PyObject *key = a->ma_table[i].me_key; /* temporarily bump aval's refcount to ensure it stays alive until we're done with it */ Py_INCREF(aval); bval = PyDict_GetItem((PyObject *)b, key); The problem is that the only reference to 'key' may be in the hash table, and test_mutants.py removes it from the hash table, apparently before the comparison code is done with using it. The fix is to incref/decref key around the GetItem call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&group_id=5470 From noreply at sourceforge.net Fri Aug 25 00:14:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 15:14:44 -0700 Subject: [Patches] [ python-Patches-1546297 ] Create a real zip iterator object; not using itertools.izip Message-ID: Patches item #1546297, was opened at 2006-08-24 15:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Brian Holmes (holmesbj) Assigned to: Nobody/Anonymous (nobody) Summary: Create a real zip iterator object; not using itertools.izip Initial Comment: This patch adds a new zipiterobject type to iterobject.c so that we do not import itertools.izip to do our iterative zip. There is test_zip.py added that is a stripped down version of the itertools test. It's my first patch so go easy on me. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 From noreply at sourceforge.net Fri Aug 25 00:23:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 15:23:53 -0700 Subject: [Patches] [ python-Patches-1546297 ] Create a real zip iterator object; not using itertools.izip Message-ID: Patches item #1546297, was opened at 2006-08-24 18:14 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Brian Holmes (holmesbj) >Assigned to: Guido van Rossum (gvanrossum) Summary: Create a real zip iterator object; not using itertools.izip Initial Comment: This patch adds a new zipiterobject type to iterobject.c so that we do not import itertools.izip to do our iterative zip. There is test_zip.py added that is a stripped down version of the itertools test. It's my first patch so go easy on me. ;) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 18:23 Message: Logged In: YES user_id=6380 I get a fatal error on the DECREF(ro) call at line 419 of iterobject.c. Investigating... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 From noreply at sourceforge.net Fri Aug 25 00:55:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 15:55:41 -0700 Subject: [Patches] [ python-Patches-1540385 ] tarfile __slots__ addition Message-ID: Patches item #1540385, was opened at 2006-08-14 21:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile __slots__ addition Initial Comment: Quicky mod, use __slots__ for TarInfo objects in tarfile module; lot of slots, but reduces memory by around 33% in testing. Pardon the delay in submitting; would like to see it in 2.5, but also well aware it's pushing it time wise. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 15:55 Message: Logged In: YES user_id=357491 I have backwards-compatibility issues with this. Adding slots to an already existing object can cause problems if people are arbitrarily adding attributes to an instance. ---------------------------------------------------------------------- Comment By: Lars Gustäbel (gustaebel) Date: 2006-08-16 06:28 Message: Logged In: YES user_id=642936 If you had run the test suite you would have noticed that there are still some names missing: buf, sparse and _link_target. Please adjust the patch. I cannot really estimate the implications of this patch. I think in terms of memory use it is reasonable to add __slots__ to Tarinfo objects because they can appear in hordes of thousands sometimes. But it could break some code, too. OTOH it is easy to reverse ;-) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-08-14 23:55 Message: Logged In: YES user_id=21627 It definitely can't get into 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1540385&group_id=5470 From noreply at sourceforge.net Fri Aug 25 00:59:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 15:59:15 -0700 Subject: [Patches] [ python-Patches-1546297 ] Create a real zip iterator object; not using itertools.izip Message-ID: Patches item #1546297, was opened at 2006-08-24 18:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Brian Holmes (holmesbj) Assigned to: Guido van Rossum (gvanrossum) Summary: Create a real zip iterator object; not using itertools.izip Initial Comment: This patch adds a new zipiterobject type to iterobject.c so that we do not import itertools.izip to do our iterative zip. There is test_zip.py added that is a stripped down version of the itertools test. It's my first patch so go easy on me. ;) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 18:59 Message: Logged In: YES user_id=6380 Deleting that line (line 419) fixes the problem. Then all tests pass. The patch has small style issues though, and I'm not sure whether the zip iter ought to have a __length_hint__ method at all. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 18:23 Message: Logged In: YES user_id=6380 I get a fatal error on the DECREF(ro) call at line 419 of iterobject.c. Investigating... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 From noreply at sourceforge.net Fri Aug 25 01:05:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 16:05:00 -0700 Subject: [Patches] [ python-Patches-1539381 ] Add readinto method to StringIO and cStringIO Message-ID: Patches item #1539381, was opened at 2006-08-12 20:16 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1539381&group_id=5470 Please note that this 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: Closed >Resolution: Rejected Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Add readinto method to StringIO and cStringIO Initial Comment: Added a 'readonly' flag to buffer object constructor (needed to implement StringIO.readinto). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 16:04 Message: Logged In: YES user_id=357491 The file object's readinto method is not meant for public use, so adding the method to StringIO is not a good idea. Sorry. Closing as rejected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1539381&group_id=5470 From noreply at sourceforge.net Fri Aug 25 01:52:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 16:52:37 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-09 23:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 16:52 Message: Logged In: YES user_id=357491 Why can't you store into an instance of StringIO instead of a temp file? ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-09 23:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Fri Aug 25 01:58:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 16:58:13 -0700 Subject: [Patches] [ python-Patches-1546297 ] Create a real zip iterator object; not using itertools.izip Message-ID: Patches item #1546297, was opened at 2006-08-24 15:14 Message generated for change (Comment added) made by holmesbj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Brian Holmes (holmesbj) Assigned to: Guido van Rossum (gvanrossum) Summary: Create a real zip iterator object; not using itertools.izip Initial Comment: This patch adds a new zipiterobject type to iterobject.c so that we do not import itertools.izip to do our iterative zip. There is test_zip.py added that is a stripped down version of the itertools test. It's my first patch so go easy on me. ;) ---------------------------------------------------------------------- >Comment By: Brian Holmes (holmesbj) Date: 2006-08-24 16:58 Message: Logged In: YES user_id=1525681 Removed the __length_hint__ stuff which clears up the uninitialized ro which caused the seg fault. Changed zip_create_iter to _PyZip_Create. Added result into zipiter_traverse and zipiter_dealloc. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 15:59 Message: Logged In: YES user_id=6380 Deleting that line (line 419) fixes the problem. Then all tests pass. The patch has small style issues though, and I'm not sure whether the zip iter ought to have a __length_hint__ method at all. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 15:23 Message: Logged In: YES user_id=6380 I get a fatal error on the DECREF(ro) call at line 419 of iterobject.c. Investigating... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:12:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:12:24 -0700 Subject: [Patches] [ python-Patches-1545507 ] ctypes and Win64 Message-ID: Patches item #1545507, was opened at 2006-08-23 21:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545507&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: ctypes and Win64 Initial Comment: The _ctypes extension is not built on Win64, because it is not yet ported to the AMD64 architecture. Since I'm working on win64 support in the ctypes SVN repo, chances are that this can be distributed and installed as standalone package for Python 2.5. To avoid problems with the installation, I recommend that the ctypes package in Lib/ctypes should *NOT* be included in the Python 2.5 AMD64 msi installer. The attached patch for Tools/msi/msi.py should implement this, although I cannot completely test it (I have not built the AMD64 version of sqlite3, no CHM file, and so on). Assigning to MvL because he builds the msi packages. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-25 02:12 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r51580 and r51581. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545507&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:13:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:13:55 -0700 Subject: [Patches] [ python-Patches-1475523 ] patch fixing #1448060 (gettext.py bug) Message-ID: Patches item #1475523, was opened at 2006-04-24 15:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470 Please note that this 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: 7 Submitted By: Thenault Sylvain (syt) Assigned to: Martin v. L?wis (loewis) Summary: patch fixing #1448060 (gettext.py bug) Initial Comment: Here is a patch for the bug described in https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470 It follows the latest Martin followup as I understand it. I'm not sure if multi-lines field handling should be totally discarded while reading metadata headers (as implemented), or if it should only be discarded for the content-type and plural-forms header. If one think this patch isn't correct, please comment so I can fix it. Notice that if the second solution was intended, lines such as "#-#-#-#-# fr.po #-#-#-#-#\n" inserted by msgcat/msgmerge will have to be treated differently (i.e. multi-lines support but skip lines begining with a #). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-25 02:13 Message: Logged In: YES user_id=21627 Couldn't get to it before 2.5; forwarding to 2.4.4/2.5.1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-17 09:45 Message: Logged In: YES user_id=21627 The patch is wrong; it breaks the existing test case WeirdMetadataTest. I think the "just a single line" rule should be restricted to Plural-Forms; not sure whether it should apply to content-type also (but why not). I'll attach another patch that adds a test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:22:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:22:28 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-10 16:57 Message generated for change (Comment added) made by djmdjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: Damien Miller (djmdjm) Date: 2006-08-25 10:22 Message: Logged In: YES user_id=1359232 As far as I can tell, StringIO doesn't actually create a filesystem object that can be manipulated. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-25 09:52 Message: Logged In: YES user_id=357491 Why can't you store into an instance of StringIO instead of a temp file? ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-10 16:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:23:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:23:41 -0700 Subject: [Patches] [ python-Patches-1546288 ] crash in dict_equal Message-ID: Patches item #1546288, was opened at 2006-08-24 15:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open >Resolution: Later >Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Neal Norwitz (nnorwitz) Summary: crash in dict_equal Initial Comment: I initially found this bug in the py3k branch, but it's reproducible in 2.5 as well (and probably older versions as well, as long as they have dict_equal()). It can be reproduced by using the attached patch to test_mutants.py. The problem is in this fragment in dict_equal(): PyObject *key = a->ma_table[i].me_key; /* temporarily bump aval's refcount to ensure it stays alive until we're done with it */ Py_INCREF(aval); bval = PyDict_GetItem((PyObject *)b, key); The problem is that the only reference to 'key' may be in the hash table, and test_mutants.py removes it from the hash table, apparently before the comparison code is done with using it. The fix is to incref/decref key around the GetItem call. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 17:23 Message: Logged In: YES user_id=33168 Defer until 2.5.1. I'll apply later. (If I forget, someone please checkin after 2.5 is out the door. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546288&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:24:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:24:59 -0700 Subject: [Patches] [ python-Patches-1545275 ] new directio module Message-ID: Patches item #1545275, was opened at 2006-08-23 15:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545275&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Omar AitMous (oaitmous) Assigned to: Nobody/Anonymous (nobody) Summary: new directio module Initial Comment: This module is an interface to the open(),read(),write() and close() system calls on a Direct I/O context (O_DIRECT flag to the open() system call). The O_DIRECT flag allows to open a file in "direct" mode -- effectively bypassing the buffer-cache. This behaviour is generally not a good thing since it will strongly degrade performances, but it can be desirable for some purposes (benchmark, or optimized read of many concurrent video streams, for instance). A special interface is needed, since the read() system calls requires aligned buffers when used on O_DIRECT file descriptors. And since the flag O_DIRECT is not available with the os module, we decided to write this module. We would like to know if this is worth for inclusion in the standard Python distribution? What should be modified to make it more "compliant" to the python rules? This file will probably need to be updated to conform to python style standards. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-25 02:24 Message: Logged In: YES user_id=21627 The major problem with this module is that it is LGPL; for inclusion in the library, a contribution form to the PSF would be required and your license be changed. In any case, it's not clear what the applicability of this specialized API is. My suggestion would be to package it up with distutils and put it on the Cheeseshop (cheeseshop.python.org). When there is an established user base, and demand that it be included in the standard distribution, inclusion should be discussed on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545275&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:57:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:57:02 -0700 Subject: [Patches] [ python-Patches-1545262 ] new splicetee module Message-ID: Patches item #1545262, was opened at 2006-08-23 15:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545262&group_id=5470 Please note that this 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 Submitted By: Omar AitMous (oaitmous) Assigned to: Nobody/Anonymous (nobody) Summary: new splicetee module Initial Comment: This module is an interface to the new splice()/tee() system calls under Linux Kernel 2.6.17 and higher. Splice allows one to transfer data from a stream to another within the kernel, without need for user-land involvement, while tee transfers data from a pipe to another without consuming the data on the first pipe. By combining both system calls, it is possible to actually do zero-copy movement of data from one or many sources to many destinations. For more information about splice() and tee() system call mechanisms : http://kerneltrap.org/node/6505 We would like to know if this is worth for inclusion in the standard Python distribution? What should be modified to make it more "compliant" to the python rules? This file will probably need to be updated to conform to python style standards. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-25 02:57 Message: Logged In: YES user_id=21627 See my comments to 1545275, packaging it up as a separate package on the Cheeseshop should be the first step. In the specific case, I think this should be added to posixmodule.c if it is added at all. I don't think the system call should be done directly, but instead, a C library interface should be used once available. Then, in turn, configure should detect presence of the API. Notice the documentation has bogus fragments of C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545262&group_id=5470 From noreply at sourceforge.net Fri Aug 25 03:03:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 18:03:51 -0700 Subject: [Patches] [ python-Patches-1546078 ] xrange that supports longs, etc Message-ID: Patches item #1546078, was opened at 2006-08-24 09:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546078&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: xrange that supports longs, etc Initial Comment: This patch is not ready for prime-time. It has various crap in it that needs to be cleaned up. I just wanted to put the current state up so we don't lose it. Once we decide on the direction this should take for 2.6 and 3k, I can finish off the patch. There is the change to rangeobject.c which contains the bulk of the changes. The bltinmodule.c change is only to support exporting the xrange iter to the python version of xrange. I've attached the xrange impl I've been playing with too. It may require some tweaks when you make little changes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 18:03 Message: Logged In: YES user_id=33168 I've attached a new version. This has all the bootstrapping necessary to import xrange and set it up properly. The C code is still a bit sloppy. The python version (which is the only one used except for the xrange iterator over C longs), is pretty clean and should work on the entire test suite. The python version has some additional features, at least supporting negative indices. It also warns on floats, not sure if the C version does that or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546078&group_id=5470 From noreply at sourceforge.net Fri Aug 25 03:19:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 18:19:47 -0700 Subject: [Patches] [ python-Patches-1546372 ] broken error reporting when filename specified by -s missing Message-ID: Patches item #1546372, was opened at 2006-08-25 11:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: broken error reporting when filename specified by -s missing Initial Comment: Traceback (most recent call last): File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 938, in ? PyBenchCmdline() File "/usr/local/src/Python-2.5c1/Tools/pybench/CommandLine.py", line 346, in __init__ rc = self.main() File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 889, in main print '* Error opening/reading file %s: %s' % ( UnboundLocalError: local variable 'reason' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 From noreply at sourceforge.net Fri Aug 25 03:22:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 18:22:35 -0700 Subject: [Patches] [ python-Patches-1546372 ] pybench.py error reporting broken for bad -s filename Message-ID: Patches item #1546372, was opened at 2006-08-25 11:19 Message generated for change (Settings changed) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) >Summary: pybench.py error reporting broken for bad -s filename Initial Comment: Traceback (most recent call last): File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 938, in ? PyBenchCmdline() File "/usr/local/src/Python-2.5c1/Tools/pybench/CommandLine.py", line 346, in __init__ rc = self.main() File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 889, in main print '* Error opening/reading file %s: %s' % ( UnboundLocalError: local variable 'reason' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 From noreply at sourceforge.net Fri Aug 25 06:27:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 21:27:41 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-10 16:57 Message generated for change (Comment added) made by djmdjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: Damien Miller (djmdjm) Date: 2006-08-25 14:27 Message: Logged In: YES user_id=1359232 Here is an diff that includes a regress test ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-25 10:22 Message: Logged In: YES user_id=1359232 As far as I can tell, StringIO doesn't actually create a filesystem object that can be manipulated. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-25 09:52 Message: Logged In: YES user_id=357491 Why can't you store into an instance of StringIO instead of a temp file? ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-10 16:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Fri Aug 25 12:30:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 03:30:31 -0700 Subject: [Patches] [ python-Patches-1546372 ] pybench.py error reporting broken for bad -s filename Message-ID: Patches item #1546372, was opened at 2006-08-25 01:19 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: lplatypus (ldeller) >Assigned to: M.-A. Lemburg (lemburg) Summary: pybench.py error reporting broken for bad -s filename Initial Comment: Traceback (most recent call last): File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 938, in ? PyBenchCmdline() File "/usr/local/src/Python-2.5c1/Tools/pybench/CommandLine.py", line 346, in __init__ rc = self.main() File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 889, in main print '* Error opening/reading file %s: %s' % ( UnboundLocalError: local variable 'reason' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 From noreply at sourceforge.net Fri Aug 25 12:31:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 03:31:23 -0700 Subject: [Patches] [ python-Patches-1545262 ] new splicetee module Message-ID: Patches item #1545262, was opened at 2006-08-23 13:01 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545262&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Omar AitMous (oaitmous) Assigned to: Nobody/Anonymous (nobody) Summary: new splicetee module Initial Comment: This module is an interface to the new splice()/tee() system calls under Linux Kernel 2.6.17 and higher. Splice allows one to transfer data from a stream to another within the kernel, without need for user-land involvement, while tee transfers data from a pipe to another without consuming the data on the first pipe. By combining both system calls, it is possible to actually do zero-copy movement of data from one or many sources to many destinations. For more information about splice() and tee() system call mechanisms : http://kerneltrap.org/node/6505 We would like to know if this is worth for inclusion in the standard Python distribution? What should be modified to make it more "compliant" to the python rules? This file will probably need to be updated to conform to python style standards. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-25 00:57 Message: Logged In: YES user_id=21627 See my comments to 1545275, packaging it up as a separate package on the Cheeseshop should be the first step. In the specific case, I think this should be added to posixmodule.c if it is added at all. I don't think the system call should be done directly, but instead, a C library interface should be used once available. Then, in turn, configure should detect presence of the API. Notice the documentation has bogus fragments of C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545262&group_id=5470 From noreply at sourceforge.net Sat Aug 26 01:27:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 16:27:08 -0700 Subject: [Patches] [ python-Patches-1546297 ] Create a real zip iterator object; not using itertools.izip Message-ID: Patches item #1546297, was opened at 2006-08-24 18:14 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brian Holmes (holmesbj) Assigned to: Guido van Rossum (gvanrossum) Summary: Create a real zip iterator object; not using itertools.izip Initial Comment: This patch adds a new zipiterobject type to iterobject.c so that we do not import itertools.izip to do our iterative zip. There is test_zip.py added that is a stripped down version of the itertools test. It's my first patch so go easy on me. ;) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-25 19:27 Message: Logged In: YES user_id=6380 I've made some small changes and checked it in (r51620): - fixed a few odd whitespace cases, e.g. for(i=0 ; into for (i = 0; - disabled the specific type error - rearranged the code so the type object is last; this reduces the number of forward decls needed - shortened a long line ---------------------------------------------------------------------- Comment By: Brian Holmes (holmesbj) Date: 2006-08-24 19:58 Message: Logged In: YES user_id=1525681 Removed the __length_hint__ stuff which clears up the uninitialized ro which caused the seg fault. Changed zip_create_iter to _PyZip_Create. Added result into zipiter_traverse and zipiter_dealloc. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 18:59 Message: Logged In: YES user_id=6380 Deleting that line (line 419) fixes the problem. Then all tests pass. The patch has small style issues though, and I'm not sure whether the zip iter ought to have a __length_hint__ method at all. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-24 18:23 Message: Logged In: YES user_id=6380 I get a fatal error on the DECREF(ro) call at line 419 of iterobject.c. Investigating... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546297&group_id=5470 From noreply at sourceforge.net Sat Aug 26 08:36:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 23:36:51 -0700 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this 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 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-25 23:36 Message: Logged In: YES user_id=357491 I just like to try to reuse the built-in exceptions as much as possible. But you are right, a new exception is the right solution. I added a BindError exception that inherits from TypeError. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:44 Message: Logged In: YES user_id=357491 OK, fixed the bug. Problem was that I had a bogus test that was testing for your example to fail. Oops. =) All fixed in the newest version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 14:34 Message: Logged In: YES user_id=764593 (4) Is there any reason you can't define a new exception type, perhaps as a subclass of TypeError? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:23 Message: Logged In: YES user_id=357491 (2) I don't want to do that because it isn't like you can't call bind() multiple times. I would hate to get a Parameter object with some suggested argument value, and then while I had it have that value change because in another thread someone called bind() on the Signature object again. (3) Fair enough. Changed to your suggestion in my version. (4) OK, I see what you are getting at. Changed in my version. I still wish there was a different exception that I could use to flag that the binding didn't fail but that the code couldn't figure out one without being destructive. (5) Yep, that's a bug. I have a test case for it now and will work on fixing it. (7) Fair enough. Code changed and docstring updated. I will work on fixing the bug I have that you reported. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:49 Message: Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 10:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 16:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 15:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Sat Aug 26 08:40:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 23:40:17 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-09 23:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-25 23:40 Message: Logged In: YES user_id=357491 Right, it doesn't create a filesystem file. But that is the point. You work in memory and then write to your final destination as needed. Your code you have pasted in the description does nothing special that requires the use of a temporary file. You can just write into a StringIO object, skip the os.link call, and then just write out to the final file location. ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-24 21:27 Message: Logged In: YES user_id=1359232 Here is an diff that includes a regress test ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-24 17:22 Message: Logged In: YES user_id=1359232 As far as I can tell, StringIO doesn't actually create a filesystem object that can be manipulated. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 16:52 Message: Logged In: YES user_id=357491 Why can't you store into an instance of StringIO instead of a temp file? ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-09 23:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Sat Aug 26 08:47:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 23:47:22 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-10 16:57 Message generated for change (Comment added) made by djmdjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: Damien Miller (djmdjm) Date: 2006-08-26 16:47 Message: Logged In: YES user_id=1359232 Well, that would a) not be an atomic replacement and b) you miss (or would have to reimplement) the mkstemp() like behaviour. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-26 16:40 Message: Logged In: YES user_id=357491 Right, it doesn't create a filesystem file. But that is the point. You work in memory and then write to your final destination as needed. Your code you have pasted in the description does nothing special that requires the use of a temporary file. You can just write into a StringIO object, skip the os.link call, and then just write out to the final file location. ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-25 14:27 Message: Logged In: YES user_id=1359232 Here is an diff that includes a regress test ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-25 10:22 Message: Logged In: YES user_id=1359232 As far as I can tell, StringIO doesn't actually create a filesystem object that can be manipulated. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-25 09:52 Message: Logged In: YES user_id=357491 Why can't you store into an instance of StringIO instead of a temp file? ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-10 16:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:20:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:20:29 -0700 Subject: [Patches] [ python-Patches-1472639 ] make range be xrange Message-ID: Patches item #1472639, was opened at 2006-04-18 18:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) >Assigned to: Neal Norwitz (nnorwitz) Summary: make range be xrange Initial Comment: As discussed (in private email), make range an alias for xrange and see howmuch breaks ;) Aside from Python/bltinmodule.c, 31 files had to be changed: 3 modules (but one of them was a doctest in doctest), 2 test output files (for profile and cProfile), and 26 tests. The predominant breakage in tests was due to tests using range() to express expected-test-output, and comparing it with the output list. Another fair sized portion (particularly of doctests, and including the doctest in doctest itself that had to be updated) broke because of reliance on the repr of range(). Only a few tests broke because of xrange() being immutable (mostly tests that were actually testing list-behaviour, like item- and slice-assignment, on a list created by range()), but that were all two real breakages in actual modules. The only place that broke because xrange can't handle longs was the test for range() that tested whether it'd take longs. Overall, ~185 lines had to be changed. The patch still breaks a test: the test to see if range() does proper checks on its arguments (using the 'badint' class in test_builtin.) I didn't fix it to remind myself that xrange() should be made to operate on longs :) (It currently fails because xrange() will turn all its arguments into C long integers before it does any checks.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 16:20 Message: Logged In: YES user_id=6380 For Neal to close when his range/xrange patch is uploaded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472639&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:21:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:21:21 -0700 Subject: [Patches] [ python-Patches-1500623 ] Remove the repr()-backticks Message-ID: Patches item #1500623, was opened at 2006-06-04 16:54 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Brett Cannon (bcannon) Summary: Remove the repr()-backticks Initial Comment: This patch removes parser support for backticks, the UNARY_CONVERT opcode and all usages of the repr()-backticks. It also adds a test to test_syntax to make sure the backticks really are gone. The patch is against r46648. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 16:21 Message: Logged In: YES user_id=6380 For Brett to check that he's done all that this patch does already, and then to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500623&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:26:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:26:11 -0700 Subject: [Patches] [ python-Patches-1500611 ] (py3k) Remove the sets module Message-ID: Patches item #1500611, was opened at 2006-06-04 16:38 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: (py3k) Remove the sets module Initial Comment: This patch removes the sets module, its documentation and tests, in addition to replacing all usages of it with the built-in set type. The patch is against r46648. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 16:26 Message: Logged In: YES user_id=6380 This patch seems out of date -- can you refresh it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500611&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:40:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:40:28 -0700 Subject: [Patches] [ python-Patches-860326 ] PyErrr_Display and traceback.format_exception_only behaviour Message-ID: Patches item #860326, was opened at 2003-12-15 08:37 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&group_id=5470 Please note that this 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 3000 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: J?rgen Hermann (jhermann) >Assigned to: Guido van Rossum (gvanrossum) Summary: PyErrr_Display and traceback.format_exception_only behaviour Initial Comment: PyErrr_Display and traceback.format_exception_only behave differently; namely, the first one prints the module of an exception, the latter not. The attached tb_problem.py illustrates the problem, it prints: Error: text Traceback (most recent call last): File "tb_problem.py", line 3, in ? raise uu.Error("text") uu.Error: text (note the diff betwen "Error:..." and "ui.Error:...") The attached patch fixes this. Python 2.2.2 has the same problem. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 16:40 Message: Logged In: YES user_id=6380 Committed in the p3yk branch as revision 51625. This isn't exactly the same patch, and also fixes the doctests that this here patch broke, but it fixes the same issue. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 04:29 Message: Logged In: YES user_id=849994 Seems like this is an item for Python 3000. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-12 22:29 Message: Logged In: YES user_id=31435 Opened this again. Anthony reverted the patch on both trunk and 2.4 branch. Whether it will be applied on the trunk again is being discussed on python-dev. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-04-12 21:17 Message: Logged In: YES user_id=31435 As noted on python-dev, the 2.4-branch backport should be reverted, because it changes visible behavior (including causing at least three of the standard tests to fail). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 17:16 Message: Logged In: YES user_id=849994 Late is better than never ;) Thanks for the patch, I applied it as rev. 45321, 45322(2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:50:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:50:21 -0700 Subject: [Patches] [ python-Patches-1513870 ] Move reduce() to functools Message-ID: Patches item #1513870, was opened at 2006-06-28 05:42 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513870&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Move reduce() to functools Initial Comment: As a follow-up to patch #1513249, this patch moves reduce() from builtins and into functools. All related documentation and tests have been changed over as well. The patch is against r47141. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 16:50 Message: Logged In: YES user_id=6380 Well, the removal was already done, and the code that was using reduce() was rewritten to avoid it rather than importing it from functools, but the rest of this patch was applied. Committed revision 51626. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513870&group_id=5470 From noreply at sourceforge.net Sun Aug 27 03:03:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 18:03:52 -0700 Subject: [Patches] [ python-Patches-1500623 ] Remove the repr()-backticks Message-ID: Patches item #1500623, was opened at 2006-06-04 13:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500623&group_id=5470 Please note that this 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 Submitted By: Collin Winter (collinwinter) Assigned to: Brett Cannon (bcannon) Summary: Remove the repr()-backticks Initial Comment: This patch removes parser support for backticks, the UNARY_CONVERT opcode and all usages of the repr()-backticks. It also adds a test to test_syntax to make sure the backticks really are gone. The patch is against r46648. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-26 18:03 Message: Logged In: YES user_id=357491 OK, Collin caught one thing I didn't. All fixed now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-26 13:21 Message: Logged In: YES user_id=6380 For Brett to check that he's done all that this patch does already, and then to close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500623&group_id=5470 From noreply at sourceforge.net Mon Aug 28 05:44:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Aug 2006 20:44:49 -0700 Subject: [Patches] [ python-Patches-1477350 ] Allow os.listdir to accept file names longer than MAX_PATH Message-ID: Patches item #1477350, was opened at 2006-04-26 21:19 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477350&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Allow os.listdir to accept file names longer than MAX_PATH Initial Comment: On windows, os.listdir currently truncates paths longer than MAX_PATH due to using a fixed-size buffer. Patch allocates a buffer of needed size. It also replaces the forward slash appended to the path with a backslash since forward slashes don't work when using a raw path. There was also a potential crash if FindClose failed. Diff'ed against 2.4.3. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-08-27 22:44 Message: Logged In: YES user_id=771074 Wheel subsequently reinvented ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-04-26 22:38 Message: Logged In: YES user_id=771074 Attaching a test script ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1477350&group_id=5470 From noreply at sourceforge.net Mon Aug 28 12:20:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 03:20:21 -0700 Subject: [Patches] [ python-Patches-1547796 ] set literals Message-ID: Patches item #1547796, was opened at 2006-08-28 10: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=1547796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: set literals Initial Comment: A rough patch implementing {1, 2, 3}-style set literals. There is no empty set literal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1547796&group_id=5470 From noreply at sourceforge.net Mon Aug 28 17:27:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 08:27:54 -0700 Subject: [Patches] [ python-Patches-1547796 ] set literals Message-ID: Patches item #1547796, was opened at 2006-08-28 06:20 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1547796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Guido van Rossum (gvanrossum) Summary: set literals Initial Comment: A rough patch implementing {1, 2, 3}-style set literals. There is no empty set literal. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-28 11:27 Message: Logged In: YES user_id=6380 Committed revision 51631. despite two (related?) flaws: (1) ../Python/symtable.c: In function `symtable_visit_expr': ../Python/symtable.c:1209: warning: enumeration value `Set_kind' not handled in switch (2) >>> {(x for x in range(10))} KeyError: 'unknown symbol table entry' >>> (Don't ask me why that was the third thing I tried with the new syntax. :-) Also, I'd love set comprehensions! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1547796&group_id=5470 From noreply at sourceforge.net Mon Aug 28 18:39:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 09:39:19 -0700 Subject: [Patches] [ python-Patches-1547796 ] set literals Message-ID: Patches item #1547796, was opened at 2006-08-28 10:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1547796&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set literals Initial Comment: A rough patch implementing {1, 2, 3}-style set literals. There is no empty set literal. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-28 16:39 Message: Logged In: YES user_id=849994 Okay, fixed the symtable issue. Hopefully other people also do weird things with the new syntax, the unit tests aren't very thorough (yet). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-28 15:27 Message: Logged In: YES user_id=6380 Committed revision 51631. despite two (related?) flaws: (1) ../Python/symtable.c: In function `symtable_visit_expr': ../Python/symtable.c:1209: warning: enumeration value `Set_kind' not handled in switch (2) >>> {(x for x in range(10))} KeyError: 'unknown symbol table entry' >>> (Don't ask me why that was the third thing I tried with the new syntax. :-) Also, I'd love set comprehensions! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1547796&group_id=5470 From noreply at sourceforge.net Mon Aug 28 19:38:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 10:38:19 -0700 Subject: [Patches] [ python-Patches-1548082 ] "for x in setliteral" peepholer optimization Message-ID: Patches item #1548082, was opened at 2006-08-28 17: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=1548082&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: "for x in setliteral" peepholer optimization Initial Comment: Like "for x in tuple_or_list", this patch rewrites "for x in set" to use a constant frozenset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 From noreply at sourceforge.net Tue Aug 29 10:33:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 01:33:01 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Tue Aug 29 10:34:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 01:34:57 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 08:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Tue Aug 29 12:35:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 03:35:59 -0700 Subject: [Patches] [ python-Patches-1546372 ] pybench.py error reporting broken for bad -s filename Message-ID: Patches item #1546372, was opened at 2006-08-25 03:19 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: lplatypus (ldeller) Assigned to: M.-A. Lemburg (lemburg) Summary: pybench.py error reporting broken for bad -s filename Initial Comment: Traceback (most recent call last): File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 938, in ? PyBenchCmdline() File "/usr/local/src/Python-2.5c1/Tools/pybench/CommandLine.py", line 346, in __init__ rc = self.main() File "/usr/local/src/Python-2.5c1/Tools/pybench/pybench.py", line 889, in main print '* Error opening/reading file %s: %s' % ( UnboundLocalError: local variable 'reason' referenced before assignment ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-29 12:35 Message: Logged In: YES user_id=38388 Fixed in revision 51647 on the trunk. Should probably also go into Python 2.5 or 2.5.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1546372&group_id=5470 From noreply at sourceforge.net Tue Aug 29 19:59:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 10:59:55 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 04:33 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 13:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 04:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Tue Aug 29 20:24:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 11:24:38 -0700 Subject: [Patches] [ python-Patches-1548082 ] "for x in setliteral" peepholer optimization Message-ID: Patches item #1548082, was opened at 2006-08-28 13:38 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: "for x in setliteral" peepholer optimization Initial Comment: Like "for x in tuple_or_list", this patch rewrites "for x in set" to use a constant frozenset. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 14:24 Message: Logged In: YES user_id=6380 Um, "for x in [1,2,3]" doesn't get any treatment. What would be the point of writing "for x in {1,2,3}" anyway? I'd rather reject this as premature optimization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 From noreply at sourceforge.net Tue Aug 29 21:08:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 12:08:50 -0700 Subject: [Patches] [ python-Patches-1548082 ] "if x in setliteral" peepholer optimization Message-ID: Patches item #1548082, was opened at 2006-08-28 17:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) >Assigned to: Guido van Rossum (gvanrossum) >Summary: "if x in setliteral" peepholer optimization Initial Comment: Like "for x in tuple_or_list", this patch rewrites "for x in set" to use a constant frozenset. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 19:08 Message: Logged In: YES user_id=849994 Argh. Like in the py3k mail, I confusedly interchanged "for x in set" and "if x in set". if x in [1,2,3] does get special treatment, and optimizing the "in" test does make sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 18:24 Message: Logged In: YES user_id=6380 Um, "for x in [1,2,3]" doesn't get any treatment. What would be the point of writing "for x in {1,2,3}" anyway? I'd rather reject this as premature optimization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 From noreply at sourceforge.net Tue Aug 29 21:09:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 12:09:44 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 19:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 17:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 08:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Tue Aug 29 23:26:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 14:26:42 -0700 Subject: [Patches] [ python-Patches-1548082 ] "if x in setliteral" peepholer optimization Message-ID: Patches item #1548082, was opened at 2006-08-28 12:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: "if x in setliteral" peepholer optimization Initial Comment: Like "for x in tuple_or_list", this patch rewrites "for x in set" to use a constant frozenset. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 16:26 Message: Logged In: YES user_id=80475 This implementation too simplistic, you need to use a subclass of frozenset that overrides the __contains__() method to return False when the argument is not hashable. Otherwise, you end-up with a semantic change for: x = {} if x in [1,2,3]: print 'Not Found' ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 14:08 Message: Logged In: YES user_id=849994 Argh. Like in the py3k mail, I confusedly interchanged "for x in set" and "if x in set". if x in [1,2,3] does get special treatment, and optimizing the "in" test does make sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 13:24 Message: Logged In: YES user_id=6380 Um, "for x in [1,2,3]" doesn't get any treatment. What would be the point of writing "for x in {1,2,3}" anyway? I'd rather reject this as premature optimization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 From noreply at sourceforge.net Tue Aug 29 23:57:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 14:57:22 -0700 Subject: [Patches] [ python-Patches-1548082 ] "if x in setliteral" peepholer optimization Message-ID: Patches item #1548082, was opened at 2006-08-28 13:38 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 Please note that this 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: Rejected Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: "if x in setliteral" peepholer optimization Initial Comment: Like "for x in tuple_or_list", this patch rewrites "for x in set" to use a constant frozenset. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 17:57 Message: Logged In: YES user_id=6380 Let me reject this as a waste of time right now. See my post "Premature optimization and all that" in the py3k list. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 17:26 Message: Logged In: YES user_id=80475 This implementation too simplistic, you need to use a subclass of frozenset that overrides the __contains__() method to return False when the argument is not hashable. Otherwise, you end-up with a semantic change for: x = {} if x in [1,2,3]: print 'Not Found' ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 15:08 Message: Logged In: YES user_id=849994 Argh. Like in the py3k mail, I confusedly interchanged "for x in set" and "if x in set". if x in [1,2,3] does get special treatment, and optimizing the "in" test does make sense. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 14:24 Message: Logged In: YES user_id=6380 Um, "for x in [1,2,3]" doesn't get any treatment. What would be the point of writing "for x in {1,2,3}" anyway? I'd rather reject this as premature optimization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548082&group_id=5470 From noreply at sourceforge.net Wed Aug 30 00:30:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 15:30:22 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 03:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 17:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 14:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 12:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 03:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Wed Aug 30 06:50:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 21:50:04 -0700 Subject: [Patches] [ python-Patches-1549049 ] Fix for structmember conversion issues Message-ID: Patches item #1549049, was opened at 2006-08-29 23:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549049&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for structmember conversion issues Initial Comment: This patch is for bug# 1545696. Patches created against 2.5c1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549049&group_id=5470 From noreply at sourceforge.net Thu Aug 31 03:06:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 18:06:34 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Thu Aug 31 07:42:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 22:42:57 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-30 18:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-30 22: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 Aug 31 13:07:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 04:07:20 -0700 Subject: [Patches] [ python-Patches-1520904 ] Fix tests that assume they can write to Lib/test Message-ID: Patches item #1520904, was opened at 2006-07-12 00:53 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: Fix tests that assume they can write to Lib/test Initial Comment: A number of bsddb tests, as well as test_tarfile, create temporary files in Lib/ or {prefix}/lib/pythonX.Y/ . This change uses tempfile.gettempdir() instead. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-31 11:07 Message: Logged In: YES user_id=1126061 This looks fine to me, and a worthwhile change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 From noreply at sourceforge.net Thu Aug 31 15:26:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 06:26:19 -0700 Subject: [Patches] [ python-Patches-1183712 ] package_data chops off first char of default package Message-ID: Patches item #1183712, was opened at 2005-04-15 08:34 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: package_data chops off first char of default package Initial Comment: If the package name is an empty string (ie the default package), all package_data files have the first character chopped off. Attached is a test package pytest.tar.gz where running python2.4 setup.py build_py produces this error: running build_py creating build creating build/lib copying __init__.py -> build/lib error: can't copy 'ATA': doesn't exist or not a regular file Also attached is a fix proposal, though I have tested this only against the test package. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-31 09:26 Message: Logged In: YES user_id=764593 I think the patch is still missing a case or two. plen represents the length of the path prefix to ignore. Today's code computes this as (len(src_dir) + 1) where the +1 is for the "/" added by os.path.join(). As you found, src_dir won't add anything (including the "/") if src_dir is empty. But it also won't add the "/" if src_dir already ends in "/ ", and it won't even add the src_dir if the path is already absolute. I'm not certain that either of these two cases can occur, but it would be safer to assume they can. My suggestion is that the stripping be smarter -- change """ # Strip directory from globbed filenames filenames = [ file[plen:] for file in self.find_data_files(package, src_dir) ] """ to """ # Strip directory from globbed filenames filenames = [ filetail(name, src_dir) for name in self.find_data_files(package, src_dir) ] """ where filetail is a helper function defined as """ def filetail(name, strip_path): if name.startswith(strip_path): kill=len(strip_path) if name[kill] == "/": kill +=1 name=name[kill:] return name """ with tests """ >>> filetail("asdf/bdededf", "asdf") 'bdededf' >>> filetail("asdf/bdededf", "asdf/") 'bdededf' """ ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2006-05-22 16:13 Message: Logged In: YES user_id=9205 I found it in another Python program (don't remember which though). So I did not think of this as an undocumented feature. I tried it and it worked (except the data file stuff :). The patch should not break any currently working setup.py installation, since src_dir is only empty when using '' (empty string) as package name. Perhaps a cleaner approach would be to forbid an empty package name instead of silently accepting it? I am not sure. At least the documentation should mention that empty package names are not allowed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 04:23 Message: Logged In: YES user_id=21627 Why are you using an empty name as the package name? There is no default package in Python, so this shouldn't work at all. ---------------------------------------------------------------------- Comment By: Hervé Cauwelier (hcauwelier) Date: 2005-10-05 07:03 Message: Logged In: YES user_id=1216236 The patch worked well for me, thanks for it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1183712&group_id=5470 From noreply at sourceforge.net Thu Aug 31 21:55:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 12:55:35 -0700 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Guido van Rossum (gvanrossum) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 19:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 22:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 19:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 17:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 08:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Thu Aug 31 23:03:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 14:03:12 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-09-01 06:03 Message: Logged In: YES user_id=595483 >> * it looks like a bunch of lines had whitespace, but no >> other changes. this makes it hard to see the real changes. I changed some tabs in ast_for_argument function to spaces - tabs and spaces are mixed, and it's hard to edit. It would have been nice if I separate that white space conversion into another patch, but since it's p3yk branch I thought it can be allowed. >> when you say it passes all tests, did you run with -u all? >> the compiler doesn't do all the tests without it (and one >> or >> two other tests too). Yup, it passes all the tests except test_frozen and test_linuxaudiodev.py(maybe because my box doesn't have audio device..?) and some skipped tests including test_bsddb3.py, etc >> in the new test, i think you need to pass a name for the >> filename param to compile. I think there was some platform >> (windows?) that crapped out with an empty filename. (if you >> copied from an existing test, then i must be remembering >> something different.) Yeah, I copied it from test_with.py, but now I'm passing a filename. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-31 14:42 Message: Logged In: YES user_id=33168 import.c: comment has double word 'added' ast.c: * why is static commented out for ast_for_arguments? * in handle_keywordonly_args, doesn't the default case need to return -1 after setting the error? * need to change the // comments to /* */ * it looks like a bunch of lines had whitespace, but no other changes. this makes it hard to see the real changes. compile.c: * i think there is a bug in the arglength calc if there are more than 255 positional args and kw_default_count since there is |= kw_default_count << 8 (2 places) * return should go on its own line like the rest of the surrounding code. * why kwonlyargs and kw_args? the underscore seems inconsistent in the compiler package, I didn't see a change to MAKE_FUNCTION similar to the one in compile.c for the opcode stack effect. the change to regrtest.py doesn't seem necessary (just an added blank line) there should be a lot more tests added for both positive and negative conditions (syntax errors). Include variants with func(**kwargs) func(*args), etc in calls. it's not good to comment out the tests in test_frozen. otherwise, we will probably forget about the problems. when you say it passes all tests, did you run with -u all? the compiler doesn't do all the tests without it (and one or two other tests too). in the new test, i think you need to pass a name for the filename param to compile. I think there was some platform (windows?) that crapped out with an empty filename. (if you copied from an existing test, then i must be remembering something different.) In testRaiseErrorWhenFuncall(), you can use self.assertRaises, at least for most of the cases. you need a test_main for this test to be run from regrtest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 From noreply at sourceforge.net Thu Aug 31 23:07:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 14:07:04 -0700 Subject: [Patches] [ python-Patches-1549670 ] Implementation of PEP 3102 Keyword Only Argument Message-ID: Patches item #1549670, was opened at 2006-08-31 10:06 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1549670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of PEP 3102 Keyword Only Argument Initial Comment: This patch is implementation of pep 3102, keyword-only parameter. Important changes include * code object now has co_kwonlyargcount to keep the number of keyword only argument - this is analogous to co_argcount. * function object now has func_kwdefaults (dictionary) to keep the mapping between keyword only arguments and defaults for them. Only kwonly argument with default values are in the dictionary - this is analogous to func_defaults. * APIs for code object changed - both C API and Python Api. PyCode_New now takes number of keyword only arguments, and new.code also takes number of keyword only arguments. * MAKE_FUNCTION now takes another oparg, which is number of default keyword only arguments - and the name of keyword only argument and its default value are in the value stack - it is similar to oparg of CALL_FUNCTION. * MAGIC in import.c changed, since bytecode is changed. That's pretty much everything that's important, and the rest is in the code itself. And my patch passes all regression tests excepts test_frozen.py, which depends on the hard-coded mashal value, which needs to be regenerated when bytecode changes. However, freeze.py is broken - specifically, modulefinder.py is broken as Guido said. So, currently, I commented it out. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2006-09-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